(UTC)
(Группа Модераторов: 1c++ moderator)
‹ Предыдущая Тема | Следующая Тема ›
Переключение на Главную Страницу Страницы: 1 ... 6 7 [8] 9 10 ... 16 ОтправитьПечать
Очень популярная тема (более 25 ответов) Провайдер OLE DB для ТП (число прочтений - 69111 )
kms
1c++ power user
1c++ moderator
Отсутствует


я хочу, чтоб сюда проложили
дорогу оттуда...

Сообщений: 4632
Зарегистрирован: 19. Мая 2006
Re: Провайдер OLE DB для ТП
Ответ #105 - 16. Октября 2007 :: 22:15
Печать  
Uzhast писал(а) 01. Октября 2007 :: 11:07:
spock писал(а) 01. Октября 2007 :: 10:58:
Про проверку памяти: ну если памяти не хватит, то мой код упадет не первым Улыбка

Ну, тут всякое может быть Улыбка В принципе, сделать проверку на ошибки памяти не сложно. Надо только не результат new на NULL проверять, а ловить std::bad_alloc Улыбка Заодно обработку ошибок можно свести в одно единственное место, что код сильно упрощает.

Там ведь с bad_alloc в vc6 (и его rtl) полная лажа.
Тебе каким образом удается с ней справляться, можешь поделиться мудростью?
Ну, т.е. чтобы в твоих модулях bad_alloc генерировался автоматически, new(nothrow) исключения не генерировал, а в целом по приложению (по остальным модулям) поведение не изменялось.
Озадачен
  
De quelle planète es-tu?
Наверх
 
IP записан
 
Uzhast
1c++ power user
Отсутствует



Сообщений: 1341
Зарегистрирован: 30. Августа 2006
Пол: Мужской
Re: Провайдер OLE DB для ТП
Ответ #106 - 17. Октября 2007 :: 04:24
Печать  
kms писал(а) 16. Октября 2007 :: 22:15:
Там ведь с bad_alloc в vc6 (и его rtl) полная лажа.
Тебе каким образом удается с ней справляться, можешь поделиться мудростью?
Ну, т.е. чтобы в твоих модулях bad_alloc генерировался автоматически, new(nothrow) исключения не генерировал, а в целом по приложению (по остальным модулям) поведение не изменялось.
Озадачен

Блин, вот ведь гады... А я этого и не знал...
Вот есть статья Microsoft по этому поводу:
http://support.microsoft.com/?kbid=167733

Но там, похоже, стандартное поведение будет установлено для приложения в целом...
  
Наверх
 
IP записан
 
Uzhast
1c++ power user
Отсутствует



Сообщений: 1341
Зарегистрирован: 30. Августа 2006
Пол: Мужской
Re: Провайдер OLE DB для ТП
Ответ #107 - 17. Октября 2007 :: 04:58
Печать  
Вот, кстати, есть одна интересная статья по этому поводу:
http://msdn.microsoft.com/msdnmag/issues/03/09/LegacySTLFix/default.aspx

Там, например, написано, что в MFC приложениях new кидает CMemoryException. Поэтому для отлова ошибок памяти можно использовать такой код:
Код
Выбрать все
		int *p;
		try {
			p = new int [5000000000];
		}
		catch (CMemoryException *) {
			cout << "catch";
		}


Выводы для ВК 1С:
- для отлова ошибок выделения памяти проверку указателя на NULL использовать нельзя.
- универсальный способ отлова ошибок выделения памяти - это catch (...) - он будет ловить и std::bad_alloc и CMemoryException.
- Но лучше всего сделать два блока catch: для bad_alloc и CMemoryException.
  
Наверх
 
IP записан
 
Uzhast
1c++ power user
Отсутствует



Сообщений: 1341
Зарегистрирован: 30. Августа 2006
Пол: Мужской
Re: Провайдер OLE DB для ТП
Ответ #108 - 17. Октября 2007 :: 05:07
Печать  
Кстати, вот что подумал...
Когда делал себе тестовый моксель для стресс-тестов, несколько раз натыкался на нехватку памяти для 1С. Выражалось это в обычном мессаджбоксе "Мало памяти". После нажатия на кнопку "ОК" 1С тупо превращалась в зомби: вроде открыта, вроде отрисовывается все нормально, но она никак не реагирует на внешние раздражители Улыбка Ее даже закрыть нельзя. Получается, в этом случае 1С надо прибивать принудительно, что ничем не отличается от аварийного завершения. Вот и думаю, а может хрен с ним с CMemoryException? Взять переопределить new, чтобы кидал bad_alloc? Тогда 1С вместо зомбирования будет кричать "Abnormal program termination" и тупо закрываться. Будет, так сказать, "экономия" в движениях мыши - не надо будет лезть в TaskMan и убивать ее руками Улыбка
  
Наверх
 
IP записан
 
Uzhast
1c++ power user
Отсутствует



Сообщений: 1341
Зарегистрирован: 30. Августа 2006
Пол: Мужской
Re: Провайдер OLE DB для ТП
Ответ #109 - 17. Октября 2007 :: 05:17
Печать  
Ну то-то они не рекомендовали использовать STL со своим компилятором... Ну гады, ну гады... Ну все у них в этом VC6 через ##пу!
  
Наверх
 
IP записан
 
kms
1c++ power user
1c++ moderator
Отсутствует


я хочу, чтоб сюда проложили
дорогу оттуда...

Сообщений: 4632
Зарегистрирован: 19. Мая 2006
Re: Провайдер OLE DB для ТП
Ответ #110 - 17. Октября 2007 :: 16:09
Печать  
"At Microsoft, we always try to make standards better!"  Очень довольный

Еще, как оказалось, по-разному вся эта ботва работает в debug и release версиях MFC.
В debug работают хандлеры, установленные через _set_new_handler, а в release - через AfxSetNewHandler (это они после непродолжительной гражданской панихиды и бросают CMemoryException*).
Но для nothrow версии все же везде работают хандлеры _set_new_handler, даже в релизе.

Короче, довольно весело.
Лучше, чтобы памяти хватало и деньги были. Улыбка
  
De quelle planète es-tu?
Наверх
 
IP записан
 
Uzhast
1c++ power user
Отсутствует



Сообщений: 1341
Зарегистрирован: 30. Августа 2006
Пол: Мужской
Re: Провайдер OLE DB для ТП
Ответ #111 - 21. Октября 2007 :: 22:36
Печать  
Нет, это просто пипец, какие сюрпризы Фокс подбрасывает. Оно оказывается жутко жрет память на выполнении EXECSCRIPT. Попробуйте запустить в цикле выполнение, например, такого запроса:

Цитата:
"EXECSCRIPT ('USE sc33 IN 2 INDEX sc33 ORDER TAG Descr')"


Где "sc33" - название файла какого-нибудь справочника. Если поставить большое количество итераций, то в TaskMan'е можно наблюдать постоянный рост памяти. Память не высвобождается до закрытия соединения с базой. При пролистывании журнала документов за год в динамическом провайдере набегает лик весом на 2-3Мб.

Лик появляется четко на EXECSCRIPT. Пробовал ставить на выполнение в цикле другие запросы - объем выделенной памяти стабилен.

Посмотрим, как будет с prg-файлами. С EXECSCRIPT жить нельзя. Во всяком случае провайдер на нем делать - дохлое занятие.
  
Наверх
 
IP записан
 
Uzhast
1c++ power user
Отсутствует



Сообщений: 1341
Зарегистрирован: 30. Августа 2006
Пол: Мужской
Re: Провайдер OLE DB для ТП
Ответ #112 - 21. Октября 2007 :: 22:40
Печать  
Собственно, не обязательно даже писать:
Код
Выбрать все
"EXECSCRIPT ('USE sc33 IN 2 INDEX sc33 ORDER TAG Descr')"


Достаточно просто написать
Код
Выбрать все
"EXECSCRIPT ('USE IN 2')"
  
Наверх
 
IP записан
 
Uzhast
1c++ power user
Отсутствует



Сообщений: 1341
Зарегистрирован: 30. Августа 2006
Пол: Мужской
Re: Провайдер OLE DB для ТП
Ответ #113 - 21. Октября 2007 :: 23:25
Печать  
Хм. Выдрал vfpoledb.dll из 2-го сервиспака для фокспра (версия 9.0.00.5815). Не помогло. :(((
  
Наверх
 
IP записан
 
spock
1c++ developer
1c++ moderator
Отсутствует



Сообщений: 822
Местоположение: Новосибирск
Зарегистрирован: 19. Мая 2006
Пол: Мужской
Re: Провайдер OLE DB для ТП
Ответ #114 - 22. Октября 2007 :: 03:36
Печать  
Вот говорил же я, что фокс неадекватен.
  
Наверх
ICQ  
IP записан
 
kiruha
1c++ power user
Отсутствует



Сообщений: 1249
Зарегистрирован: 11. Апреля 2007
Re: Провайдер OLE DB для ТП
Ответ #115 - 22. Октября 2007 :: 08:13
Печать  
Вообще то команда USE означает команду выделить память.
"IN" указывает назначить идентификатор этой области памяти.

Как то странно выполнить команду "выделения памяти" , а потом удивляться -
"Fox жрет память". Ну а последний штрих - все это забацать в цикле !!!
Ну зачем в цикле открывать таблицы???

Что касается OLEDB то там последовательный доступ действительно не реализован нормально.
А почему для такого доступа нельзя использовать другие библиотеки?
(например встроенный в 1С XBase)
  
Наверх
 
IP записан
 
Uzhast
1c++ power user
Отсутствует



Сообщений: 1341
Зарегистрирован: 30. Августа 2006
Пол: Мужской
Re: Провайдер OLE DB для ТП
Ответ #116 - 22. Октября 2007 :: 10:05
Печать  
kiruha писал(а) 22. Октября 2007 :: 08:13:
Вообще то команда USE означает команду выделить память.
"IN" указывает назначить идентификатор этой области памяти.

Как то странно выполнить команду "выделения памяти" , а потом удивляться -
"Fox жрет память". Ну а последний штрих - все это забацать в цикле !!!
Ну зачем в цикле открывать таблицы???

Опаньки. Не ожидал от тебя такого. USE IN НомерОбласти означает наоборот - ЗАКРЫТЬ  все открытые таблицы в данной области. Т.е. это НАОБОРОТ - освобождение памяти.
Товарищ, читай документацию по Фоксу, это очень полезно.

А память течет даже при выполнении в цикле команды "return 1".
  
Наверх
 
IP записан
 
Uzhast
1c++ power user
Отсутствует



Сообщений: 1341
Зарегистрирован: 30. Августа 2006
Пол: Мужской
Re: Провайдер OLE DB для ТП
Ответ #117 - 22. Октября 2007 :: 10:06
Печать  
kiruha писал(а) 22. Октября 2007 :: 08:13:
Что касается OLEDB то там последовательный доступ действительно не реализован нормально.
А почему для такого доступа нельзя использовать другие библиотеки?
(например встроенный в 1С XBase)

OLE DB здесь не при чем - это косяки фоксового провайдера.
  
Наверх
 
IP записан
 
Uzhast
1c++ power user
Отсутствует



Сообщений: 1341
Зарегистрирован: 30. Августа 2006
Пол: Мужской
Re: Провайдер OLE DB для ТП
Ответ #118 - 22. Октября 2007 :: 10:13
Печать  
kiruha писал(а) 22. Октября 2007 :: 08:13:
Вообще то команда USE означает команду выделить память.
"IN" указывает назначить идентификатор этой области памяти.

Как то странно выполнить команду "выделения памяти" , а потом удивляться -
"Fox жрет память". Ну а последний штрих - все это забацать в цикле !!!
Ну зачем в цикле открывать таблицы???

Более того. В цикле открывается таблица в одной и той же области. В этом случае, если в области есть открытая таблица, Фокс автоматом закрывает предыдущую и открывает следующую. Поэтому открытие/закрытие одной и той же таблицы в цикле никак не может приводить к утечкам памяти. Да, с чтением документации у тебя определенно проблемы.
  
Наверх
 
IP записан
 
kiruha
1c++ power user
Отсутствует



Сообщений: 1249
Зарегистрирован: 11. Апреля 2007
Re: Провайдер OLE DB для ТП
Ответ #119 - 22. Октября 2007 :: 10:49
Печать  
Uzhast писал(а) 22. Октября 2007 :: 10:05:
Опаньки. Не ожидал от тебя такого. USE IN НомерОбласти означает наоборот - ЗАКРЫТЬ  все открытые таблицы в данной области. Т.е. это НАОБОРОТ - освобождение памяти.
Товарищ, читай документацию по Фоксу, это очень полезно.

А память течет даже при выполнении в цикле команды "return 1".


Там приведены 2 команды - я про предыдущую
Цитата:
EXECSCRIPT ('USE sc33 IN 2 INDEX sc33 ORDER TAG Descr')"

Про закрытие - я же сам привел этот код для очистки : http://www.1cpp.ru/forum/YaBB.pl?num=1191570663#7 (в конце), так что "наезд" непонятен.

По прежнему не понятно, зачем закрывать в цикле, если нет открытия.

Uzhast писал(а) 22. Октября 2007 :: 10:13:
Более того. В цикле открывается таблица в одной и той же области. В этом случае, если в области есть открытая таблица, Фокс автоматом закрывает предыдущую и открывает следующую. Поэтому открытие/закрытие одной и той же таблицы в цикле никак не может приводить к утечкам памяти. Да, с чтением документации у тебя определенно проблемы.


До этого нигде не было написано что ты открываешь таблицы в одной области.
После IN может быть что угодно.

P.S> Ладно , если обидел извини, не подумал, что мой вопрос заденет.
  
Наверх
 
IP записан
 
Переключение на Главную Страницу Страницы: 1 ... 6 7 [8] 9 10 ... 16
ОтправитьПечать
‹ Предыдущая Тема | Следующая Тема ›
 
  « Главная ‹ Раздел Вверх  



Valid RSS Valid XHTML Valid CSS Powered by Perl Source Forge