|  22.03.2012, 14:21 | #1 | 
| Участник | Множественные запросы по DataArea и VirtualDataAreaList 
			
			Столкнулся с проблемой производительности при первичном открытии формы, после перехода на DAX 2009. Ситуация следующая: В системе есть примерно 2000 компаний и еще ~20 виртуальных компаний. При открытии тогоже стандартного плана счетов, система начинает делать множественне запросы к DataArea и VirtualDataAreaList. В Ledgertable план счетов настроен на одну виртуальную компанию, т.е. у всех один план счетов. В итоге первый раз форма открывается у пользователей от 1 до 3х минут. В последующие разы запросы уже не уходят к БД. Да, в инфологе пишет, что план запроса используется повторно, но кол-во запросов меня пугает ~3000 Посмотрел на метод CursorNotify источника данных на строчке: X++: ledgerTableCache = ledgerTable_ds.getFirst(0,false);если сделать: X++: ledgerTableCache = ledgerTable_ds.getFirst(0, true);В общем, как разогнать не понятно. Есть идеи? P.S. пробовал коментить все кроме super(), в CursorNotify но это ни к чему не привело. Последний раз редактировалось Dreadlock; 22.03.2012 в 14:45. | 
|  | 
|  22.03.2012, 14:32 | #2 | 
| Участник | 
			
			Из-за виртуальных компаний в некоторых индексах полезно dataareaid  засовывать в конец. Также иногда проще переписать запрос с виртуальными компаниями. Некоторые джоины приходится рвать на несколько запросов, в таком случае запросы получаются намного проще. На форуме немножко было про это, поищите. | 
|  | 
|  22.03.2012, 14:33 | #3 | 
| Участник | 
			
			Если план счетов един у всех компаний, то, возможно, лучше отказаться от виртуальной компании в части плана счетов, а просто поменять свойство таблицы SaveDataPerCompany=No.
		 | 
|  | |
| За это сообщение автора поблагодарили: Logger (1). | |
|  22.03.2012, 14:53 | #4 | 
| Участник | Цитата: 
		
			Сообщение от Logger
			   Из-за виртуальных компаний в некоторых индексах полезно dataareaid  засовывать в конец. Также иногда проще переписать запрос с виртуальными компаниями. Некоторые джоины приходится рвать на несколько запросов, в таком случае запросы получаются намного проще. На форуме немножко было про это, поищите. | 
|  | 
|  22.03.2012, 14:58 | #5 | 
| Участник |  Вы не делаете. Аксапта за вас делает при работе. В общем, простых путей нет. Включайте трассировку долгих запросов SQL, ищите узкие места и исправляйте. | 
|  | 
|  22.03.2012, 15:20 | #6 | 
| Участник | Цитата: Есть только множественные запросы. Вот включил профайлер, смотрю он переберает все компании и отправляет ~3000 запросов на сервер и потом кэширует все это дело.  Сейчас посмотрю еще план исполнения, может и отковыряю чего. А виртуальных компаний похоже три оказалаось (для плана счетов), не получится отказатться от DataAreaId, да и не у одной формы это проявляется, т.е. есть формы, при открытии которых в первый раз на сервер уходят теже запросы, что и при открытии Плана счетов. | 
|  | 
|  22.03.2012, 17:03 | #7 | 
| Участник | 
			
			Ну поставьте апертуру 50 и посмотрите на самый частый запрос.
		 | 
|  | 
|  23.03.2012, 17:46 | #8 | 
| Участник | 
			
			В общем если есть дисплэйный метод, то выполняется куча запросов к БД, если его убрать, то все работает быстро. В Ах 3.0 работает иначе. | 
|  | 
|  18.07.2012, 17:11 | #9 | 
| Участник | 
			
			Выпустили private хотфикс по этому поводу, все полетело. P.S. еще сказали, что попутно исправили кучу багов, сборка для всех будет видимо уже только со следующим ролапом. | 
|  | |
| За это сообщение автора поблагодарили: Logger (1). | |
|  18.07.2012, 19:21 | #10 | 
| Участник | 
			
			Что правили то ? Ядро ? | 
|  | 
|  18.07.2012, 20:03 | #11 | 
| Участник | 
			
			Видимо, речь об этом: Цитата: 
		
			May 2012 KB2707970 Kernel Slow loading of forms using display methods when using virtual companies with large number of companies or large number of groups; excessive RPC calls are generated. Цитата: 
		
			2703293 Regular AOS crashes in Ax32Serv!SqlStmt::next coming from a client serverNext call RFH 2695155 Swedish charaters do not display correctly in Workflow Instruction box on Enterprise Portal 2693408 Customer base data report error- "A section in the report is higher than the actual page size allows" if you have any printer but an Microsoft XPS Document Writer on RU 7 Kernel or greater 2690074 Letter "a" in the filter field in places (list pages) clears the field content entered so far 2679864 DLL AXHotKey switches to QWERTY 2676477 Running a specific job crashes the AOS 2675310 KB2578033 breaks several SSRS reports 2674839 AOS crash in Ax32Serv!interpret::xal_asg_sym_opr 2674834 Event log when using Batch helpers 2674579 Dialog form OK/Cancel button missing when connecting to AX Client via Remote Apps 2667355 Unreadable barcode when printing to PDF | 
|  | |
| За это сообщение автора поблагодарили: Logger (5). | |
|  24.07.2012, 11:43 | #12 | 
| Участник | |
|  | |
| За это сообщение автора поблагодарили: Logger (2). | |
| Теги | 
| build, hotfix, hotfixlist, kernel rollup, virtual company, баг, виртуальные компании, производительность, хотфикс, ядро | 
|  | 
| 
 |