1с лог как внешний источник данных, проблемы с размером и памятью #728958

есть файл в новом формате 1Cv8.lgd, размер 40 гигов в 1с сделал внешний источник данных и на сервере вылетает по памяти.... ТОР 1000 не работает, говорит ошибка синтаксиса...

Жесть, жесть, жесть.

vde, я тебя не узнаю.

1) Обрабатывать порциями. 2)

как сделать напрямую я знаю, я хотел в кои веки поюзать ВнешниеИсточникиДанных а на сколько я понимаю он тупо заливает во времянку весь источник?

У тя падает на запросе или на ТЗ?

на запросе

Limit попробовал?

в 1сных запросах нет слова LIMIT

вешать сервак страшно, нету у нас тестового.... сейчас взял маленький файл, вроде все работат. После обеда посмотрю профайлером запрос к скулю...

Фирма 1C в своем репертуаре. Вспоминается анекдот - Я сотрудниками управляю методом кнута и пряника - Я пробовал так, но не очень понравилось. - Почему? - Пряником бить не удобно. Так вот такое же ощущение, что даже когда 1С хочет предложить потребителям пряник, она им очень больно ударяет. Зачем было делать лог в sqlite? Весь мир спокойно пишет логи в текстовые файлы и не жужжит. Просто периодически запускается какой-нить анализатор, который колбасит все в нужную форму. Ну ладно, сделали лог в sqlite, бог с ним. Но почему пользователям не дали нормального средства работы с такими базами? В той же семерке есть 1sqlite и нормальный поставщик данных для ТабличногоПоля, туда загнать этот ЖР для просмотра - не пикнет даже, все покажет. Внешние источники данных - тоже та еще кривость. На что не посмотришь - всё как-то они очень странно реализуют. Извините, накипело. По теме - в sqlite пишут не в начале запроса "top N", а в самом конце "limit N".

Текстовик на 40 Гб... Имхо, как-то не очень. Думаю, лучше перегонять просто в таблицу на скуле через IS.

>>> Весь мир спокойно пишет логи в текстовые файлы и не жужжит. Смысл писать туда, откуда его не прочтешь и за год. Есть пример БД, где текстовый лог за Сутки открывается средствами 1С вечность :)

+ Внешние источники данных Согласен, гадость еще та. Проще через АДО реализовать :)

(10,13)+100 logrotate ?

Именно.

одинэс, похоже, обрабатывает порциями, как сказали выше а тут, скорее всего, лежат необработанные логи: C:UsersUSR1CV8AppDataLocalTemp1c_logs

профайлером очень странно это выглядит.... сначало куча запросов (штук 200) типа exec sp_executesql N'SELECT T1._ConnectPrms FROM dbo._ExtDataSrcPrms T1 WITH(NOLOCK) WHERE T1._UserId = AND T1._ExtDataSrcId = @P2',N' varbinary(8000),@P2 varbinary(8000)',0xA63CD1E2950F8B5547C2866BBCB191DC,0x9FDDE39FDB8E6A944CE1FDC06B0403BD exec sp_executesql N'SELECT T2._IDRRef, T2._Version, T2._Marked, T2._Date_Time, T2._Completed, T2._Number, T2._HeadTaskRRef, T2._Started, T2._Fld11043RRef, T2._Fld11044_TYPE, T2._Fld11044_RTRef, T2._Fld11044_RRRef, T2._Fld11045_TYPE, T2._Fld11045_RTRef, T2._Fld11045_RRRef, T2._Fld11046, T2._Fld11047_TYPE, T2._Fld11047_RTRef, T2._Fld11047_RRRef, T2._Fld11048, T2._Fld11049RRef, T2._Fld11050RRef, T2._Fld11051RRef, T2._Fld11052, T2._Fld11053, T2._Fld11054RRef, T2._Fld11055, T2._Fld11056, T2._Fld11057, T2._Fld11058RRef, T2._Fld11477RRef, 0 AS SDBL_IDENTITY FROM dbo._BPr11013 T2 WHERE T2._IDRRef = AND T2._Version <> @P2',N' varbinary,@P2 varbinary(8000)',0xB9AB00265582BC2211E4803CCDB5F2D7,0x000000000047AD39 короче с ходу не разберешся :) но одно понятно - запросов очень много....

в скуль его втягивай и уже от туда читай. Ни чего же не мешает каждую ночь: 2. загрузить в скуль 3. грохнуть оригинальный ldg при успешной загрузке