Dla systemu Windows 2008, po zainstalowaniu poprawki Windows Update KB890830 (listopad 2010), w aplikacjach www pakietu asix może wystąpić błąd:
„System.InvalidOperationException: Nie można wygenerować tymczasowej klasy (wynik=1)”. 
powiększ
Problem wynika z niewłaściwego działania wspomnianej poprawki Windows Update i związany jest ze zmianą poziomu uprawnień dla serwera sieci Web (IIS) do folderu %systemroot%\Temp (domyślnie: C:\Windows\Temp).
W celu usunięcia wspomnianego błędu należy użytkownikowi IIS_IUSERS dodać prawa odczytu do folderu systemowego %systemroot%\Temp (np.: C:\Windows\temp)

|
Typ sterownika |
Adres zdalny TSAP |
|
S7-400 |
03.03 lub 03.04 |
|
S7-300 |
03.02 |
|
S7-200 |
10.00 lub 10.02 |
|
S7-1200 |
03.00 lub 03.01 |
Na przykład:
1,COM3, 9600,8,none,1
Dla komunikacji ze sterownikiem numer 1 poprzez port COM3. Brak opisanych opcji powoduje pracę z domyślnymi ustawieniami portu, które są inne, niż podane dla S-Bus z opcją DATA.
Konwerter wywoływany jest z poziomu Architekta z menu Narzędzia. Wymaga podania ścieżki dostępu do źródłowego pliku *.DAT z definicją trendów, wskazania bazy definicji zmiennych, w której zdefiniowane są zmienne trendów oraz zadeklarowania katalogu wyjściowego, do którego zapisane zostaną nowe trendy.
Konwersja umożliwia zachowanie wszystkich dotychczasowych ustawień konwertowanych trendów oraz dodanie nowych cech w oparciu o wzorcowy plik *.TRNX, który można zadeklarować w opcjonalnym polu konwertera. W przypadku różnych wartości tej samej własności trendu, pierwszeństwo mają ustawienia z pliku *.DAT.
Zastosowanie konwertera trendów pozwala zminimalizować czas/koszt wykonania ręcznych przeróbek definicji starych trendów na nowe, w szczególności przeróbek akcji operatorskich (np. na stacyjkach analogowych) wywołujących stare trendy. asix po rozpoznaniu akcji operatorskiej starego trendu w miejsce definicji z pliku *.DAT otwiera nowy skonwertowany trend z pliku *.TRNX.
Konwerter ma duże znaczenie użytkowe podczas przechodzenia w istniejących aplikacjach ze starych wersji systemu asix na wersję 5 z minimalną ingerencją w aplikację.
asix w wersji 2 do 4:

Zaznaczony na czerwono parametr powoduje opóźnienie o 10 sekund startu aplikacji zdefiniowanej w pliku MojaAplikacja.ini
asix w wersji 5:

Zaznaczony na czerwono parametr spowoduje opóźnienie o 10 sekund start aplikacji dla komputera o nazwie Komp1 według definicji projektu z pliku MojaApl.xml.
Podany tu czas 10s jest przykładowy – należy doświadczalnie dobrać możliwie najkrótszy czas dający gwarancję poprawnego startu aplikacji.
Przykładowy skrypt może wyglądać tak:
pobierz plik beety.rar (2 KB).
Skrypt ustawia 16 bitów w zmiennej o nazwie Bity_00_15.
Deklaracja użycia skryptu zależy od wersji pakietu. W przypadku pakietu asix w wersji 3 lub 4 użycie skryptu należy zadeklarować w pliku INI w następujący sposób:
[skrypty]
_Bity_ = skrypty\beety.js //watek:nowy,4
gdzie:
_Bity_ - nazwa skryptu, pojawia się np. w Panelu Kontrolnym przy wyprowadzaniu komunikatów
Skrypty\beety.js – nazwa pliku wykonywanego wraz ze ścieżką
//watek:nowy,4 – deklaracja utworzenia oddzielnego watku o priorytecie 4 do wykonywania tego skryptu.
W przypadku pakietu asix w wersji 5 deklarację skryptu należy wykonać w odpowiedniej zakładce Architekta (patrz rysunek poniżej). Znaczenie wpisów podobne jak w przypadku deklaracji w pliku INI aplikacji.

Szczegóły na ten temat zawiera poniższy plik PDF:
Architekt - przełączanie kanałów (186 KB)
Aby rozwikłać ten problem, należy definiując zestaw zmiennych, odsłonić również systemowe pola rekordu definicji receptury. W tym celu należy kliknąć prawym klawiszem myszki na wierszu nagłówków kolumn w widoku zestawu zmiennych

i wybrać opcję Pokaż wszystkie pola. Spowoduje to odkrycie pól systemowych.

Teraz systemowemu polu Nazwa należy przypisać zmienną zawierającą nazwę receptury (zakreślona na czerwono). Zmienna może być równocześnie przypisana do pola zdefiniowanego przez projektanta (tu: _Nazwa_).
Na masce należy zdefiniować obiekt NAPIS, który pozwoli na wyświetlenie nazwy aktualnie wybranej receptury. Jeśli niezbędne jest umożliwienie użytkownikowi definiowania nowych receptur, to właśnie ten obiekt pozwoli na podanie nowej nazwy receptury. Wprowadzenie nowej nazwy receptury (w obiekcie NAPIS) i potwierdzenie sterowania, a nastepnie wykonanie akcji ASBASE z opcją DODAJ (oraz identyfikatorem połączenia do AsBase'a) spowoduje dodanie nowej receptury.
Czasem jednak w aplikacji istnieje konieczność zadeklarowania zmiennych tekstowych (liczba elementów > 1, funkcja przeliczająca NIC_TEXT) do przechowywania, wprowadzania i wyświetlania nazw produktu, numeru partii, zamówienia lub nazwy receptury. W takim przypadku do archiwizacji tych zmiennych należy użyć modułu AsBase, dostępnego w każdym pakiecie bez dodatkowych dopłat.
AsBase to moduł obsługi baz danych MS SQL (serwer SQL dostarczany jest z asixem na płytce instalacyjnej). Jego głównym przeznaczeniem jest obsługa receptur (tworzenie, edycja, zadawanie) oraz archiwizacja dowolnie skonfigurowanego rekordu, zawierającego dane z aplikacji asix. Dane te mogą być dowolnego typu (również tekstowe) i archiwizowane w zadanym reżimie czasowym (podobnie jak archiwizacja przy użyciu Aspada) lub w odpowiedzi na zdarzenie w aplikacji, sygnalizowane na zmiennej synchronizującej zapis. Co więcj, zmienna synchronizująca zapis może służyć do zwrotnego potwierdzenia sterownikowi dokonania czynności archiwizacyjnych. System archiwizacji AsBase’a pozwala na tworzenie zapisów odnoszących się do konkretnych partii wyrobów lub pojedynczych egzemplarzy identyfikowanych po nazwie, numerze seryjnym, numerze partii, dacie i czasie lub tp.
Receptury i archiwa mogą być przeglądane na maskach aplikacji z użyciem standardowych obiektów wizualizacyjnych (LICZBA, NAPIS – teksty i inne) i przez zastosowanie akcji ASBASE z odpowiednimi parametrami.
Szczególnie interesująco przedstawia się tu możliwość zapamiętania czasu rekordu archiwalnego i przypisania go do zmiennej stałoprzecinkowej 32-bitowej (funkcja przeliczająca NIC_DW). Otóż podczas przeglądania archiwum wartości czasu będą podstawiane do tej zmiennej i wyświetlane na ekranie (format wyświetlania w obiekcie LICZBA: ‘D’). Jeśli użyje się tej zmiennej jako parametru przekazującego czas w akcji ASTREND - wykonywanej gdy na ekranie jest wyświetlany żądany rekord, to początek czasu w oknie programu AsTrend będzie ustawiony właśnie na wartość odczytaną z AsBase’a. Pozwala to na natychmiastowe odszukanie w archiwach Aspada przebiegu zmian wielkości analogowych związanego z danym rekordem (czytaj: partią, szarżą, wyrobem).
Mój komputer > Właściwości > Zaawansowane > Wydajność_Ustawienia > Zapobieganie wykonywaniu danych

2. W zakładce parametrów startowych należy zadeklarować nazwę pliku ZEZ i jego lokalizację, która może być dowolna i wybrana przyciskiem [...] ): 
3. Następnie należy sprawdzić, czy baza jest widoczna w Architekcie - z menu u góry okna Architekta należy wybrać Baza definicji zmiennych > Pokaż... Jeśli wszystko jest poprawnie zadeklarowane i baza jest dostępna, to powinno pojawić się okno bazy zmiennych takie jak w asixie 3 i 4.
Etapy konwersji bazy z wersji asixa 3 / 4 do formatu bazy asixa 5 (710 KB)
Jeśli w odpowiednim arkuszu skoroszytu MS Excel z definicjami zmiennych są poprawnie zadeklarowane argumenty funkcji przeliczających, a w wygenerowanej bazie odpowiednie pola pozostają niewypełnione - powodem takiego stanu rzeczy są pewne błedy formatu komórek arkusza kalkulacyjnego lub nieprawidłowe działanie drajwera MDAC firmy Microsoft. Najprostszym rozwiązaniem problemu jest bądź zainstalowanie nowszego drajwera plików XLS z pakietu MS Office 2007, bądź wybór drajwera wbudowanego w pakiet asix. Sposób wyboru został opisany w:
„Q: Po przeniesieniu aplikacji z komputera projektanta i przy zachowaniu dokładnie takiej samej lokalizacji składowych elementów aplikacji wszystko działa poprawnie, ale z poziomu Architekta nie udaje się wygenerować bazy zmiennych. Dlaczego?” (2008-08-25).
,
a następnie w Opcjach, w zakładce Źródła danych przełącznikiem dokonać wyboru tzw. silnika odczytu plików XLS - jak pokazano na rysunku poniżej:
