If you have a 3-tier AOS application that is running on several AOS in a cluster, sometimes developing can be a pain.
Besides the old known trick of duplicating the menu items SysFlushAOD, SysFlushData and SysFlushDictionary and set the duplicates to run on server, here's another hint.
The AOS will know about each other's changes in the AOT in some minutes time. But this will not work if you make changes in the data dictionary.
Following example: in a table, you create a new index with several fields and synchronize it to the database.
After that, you enter Axapta on another AOS. What will you see in the index list for the table ?
--> The index you just created is called "UNKNOWN" (but has the fields inside).
What you have to do now is call the SysFlushDictionary menu item (the one that is running on server or even better both of them, but first the one running on server).
Et voilá. You will see the index in the AOT.
vor 1 Woche
2 Kommentare:
Developing in a live application is asking for trouble. Beyond reports all development should be done in an isolated environment, tested, and tehn moved to Live during a planned time frame with appropriate backups. And developing changes to the Data model is pure suicide in a production environment. Changing data structure on tables while users might be accessing them is a quick way to data corruption in my experience.
Apply changes by getting all users off the system, roll in your changes, then restart each AOS before allowing users back in. And of course ensure you have valid backups of the application and database.
link alternatif s128 www.s128.net sabung ayam
Kommentar veröffentlichen