Как известно uzhast исправил дравйвер http://uzhast.fatal.ru/vfpoledb/

Цитата:


Нисколько не умаляя заслуг uzhast тем не менее должен заметить, что существует более изящное  решение проблемы

Команда
Цитата:


Таким образом после создания соединения достаточно выполнить команды

ОлеДБКоманда = глОлеДБ.СоздатьКоманду();
ОлеДБКоманда.Выполнить("EXECSCRIPT('SET EXCLUSIVE  OFF')");   

аналогично, если например нужно включить режим для вставки или модернизации данных

ОлеДБКоманда = глОлеДБ.СоздатьКоманду();
ОлеДБКоманда.Выполнить("EXECSCRIPT('SET EXCLUSIVE  ON')");   

Таким образом можно всегда пользоваться родным и наиболее свежим драйвером
и более тонко подходить к вопросу блокирования таблиц.

Nick писал(а) 12. Марта 2008 :: 10:17:


Поясни

kiruha писал(а) 12. Марта 2008 :: 10:20:


То что ты раскопал ни как не влияет на блокировки связанные с записью данных. Это параметр эквивалентен открытию 1с в монопольном режиме. Т.е. таблица полностью блокируется одним пользователем, и пока он её не закроет фиг кто ещё к ней обратится

Nick писал(а) 12. Марта 2008 :: 10:24:


И что? (не буду придираться к "эквивалентен" -все таки это не так - но будем считать что аналогичен).
Именно это я и писал.

Да возьмите и проверьте.

vfpoledb SP2: не подтверждается. В модуле проведения после выполнения движений вставляю Предупреждение.
Далее во втором экземпляре 1С выполняю запрос с предварительным SET EXCLUSIVE OFF. Результат:
Цитата:

Таким образом, SET EXCLUSIVE не влияет на успешность чтения драйвером Фокспро заблокированной таблицы.

Может, конечно, драйвер не самый новый.

Я вообще то думаю что Uzhast боролся с другими блокировками или нет?

Uzhast писал(а) 12. Марта 2008 :: 10:44:


драйвер последний http://www.microsoft.com/downloads/details.aspx?FamilyId=E1A87D8F-2D58-491F-A0FA...

Провел много тестов. По методике Uzhast в том числе. Все ОК.
Вероятно ты делаешь"SET EXCLUSIVE  OFF" для разных  ОлеДБ - при этом настройка действует
только в рамках ОлеДБ .

В общем, так. Хватит вешать людЯм лапшу на уши. Запутал ты меня. EXCLUSIVE может быть только в двух положениях ON и OFF. Если БЫ он был в ON изначально, то запросы вообще бы нельзя было бы выполнять к текущей базе - файлы открыты 1С. Значит, этот переключатель УЖЕ в OFF. Поэтому твой скрипт ВООБЩЕ ни на что не влияет.

kiruha писал(а) 12. Марта 2008 :: 11:32:

Сдается мне, что это эффект из-за того, что таблица не закрывается фоксом после выполнения запроса. Но ведь он же тогда кеширование некое производит - я уже натыкался на это. Поэтому, если пользоваться такой вещью, то, ИМХО, возможны проблемы. Нет уж, я таким рецептом пользоваться не рискну.

Тьфу, блин. Выше "SET EXCLUSIVE ON" читать как "SET EXCLUSIVE OFF"

Предварительно прав Uzhast - дело в кэше.

Только кэшируются не данные, а структура открытых таблиц.
Если в сессии была открыта хотя бы одна запись таблицы(до блокировки другим пользователем) - после этого
без проблем можно открывать любые записи этой таблицы во время проведения другого пользователя...
Т.е. блокировка распостраняется только на чтение структуры

Nick писал(а) 12. Марта 2008 :: 16:19:


Да нет - все верно. SET EXCLUSIVE OFF делает возможным многопользовательский режим
работы - Фокспро не блокирует при запросах других пользователей.
Кстати эта опция как правило устанавливается во время соединения по умолчанию.

Но есть еще 2 проблема - выполнения запросов во время проведения документов 1С.
Дело в том, что эта опция естественно не распостраняется на не ФоксПро системы.
К счастью 1С блокирует только чтение структуры файла.

Для того чтобы сделать возможным использование запросов ФоксПро во время проведения
определяем глобальную пременную глОлеДБ.
В процедуре ПриНачалеРаботыСистемы() Вызываем ИнициализацияТаблицФокспро()
- аналог открытия файлов 1С во время входа в программу

Процедура ИнициализацияТаблицФокспро()
	глОлеДБ = СоздатьОбъект("OLEDBData");
	Рез=глОлеДБ.Соединение("
	|Provider=VFPOLEDB.1;
	//	|Deleted=Yes;
	|Null = Yes;
	|Exclusive = No;
	|SourceType = DBF;
	|Data Source=" + КаталогИБ() + ";
	|Mode=ReadWrite;
	|Extended Properties="""";
	|User ID="""";
	|Password="""";
	|Mask Password=False;
	|Collating Sequence=MACHINE;
	|DSN=""""");
	//  Так как стоит Exclusive = No скрипт  SET EXCLUSIVE OFF не нужен
	локОлеДБКоманда = глОлеДБ.СоздатьКоманду();
	локОлеДБКоманда.Выполнить("EXECSCRIPT('SET ANSI OFF')");
	// Устанавливаем время ожидания захвата таблиц , если во время выполнения запроса кто то проводит документы
	// Очень полезная функция - аналогична времени ожидания в 1С
	локОлеДБКоманда.Выполнить("EXECSCRIPT('SET REPROCESS TO 60 SECONDS')");
// Убираем буфепизацию, чтобы данные возвращаемые запросам всегда были актуальны
	 локОлеДБКоманда.Выполнить("EXECSCRIPT('SET REFRESH TO 0,-1')");
	ВремяНачалоЗапроса=_GetPerformanceCounter();
	// Откроем таблицы Регистра итогов. Для минимального времени используем основной индекс
	Для ИИ=1 По Метаданные.Регистр() Цикл
		МетаданныеРегистр=Метаданные.Регистр(ИИ);
		ИдентификаторРегистра=МетаданныеРегистр.Идентификатор;
		СтрокаПеременныхПоля=" DTOS(РегОстатков.period) ";
		Для ЛЛ=1 По МетаданныеРегистр.Измерение() Цикл
			ИзмерениеРегистра=МетаданныеРегистр.Измерение(ЛЛ);
			д,ИзмерениеРегистра.Длина,ИзмерениеРегистра.Точность,"РегОстатков");
		КонецЦикла;
		текстЗапроса="
		| SELECT
		|
		|РегОстатков.period
		|
		|FROM $РегистрИтоги."+ИдентификаторРегистра+" as РегОстатков
		|WHERE "+СтрокаПеременныхПоля+"='12345678'
		|";
		локОлеДБКоманда.Выполнить(текстЗапроса);
		текстЗапроса="
		| SELECT
		|
		|РегОстатков.iddoc
		|
		|FROM $Регистр."+ИдентификаторРегистра+" as РегОстатков
		|WHERE
		|";
		локОлеДБКоманда.Выполнить(текстЗапроса);


	КонецЦикла;
	//Таблица констант
	текстЗапроса="
	| SELECT
	|
	|Константа.docid
	|
	|FROM 1SCONST as Константа
	|WHERE Константа.docid+STR(Константа.actno,6)+STR(Константа.partno,3)='123456789'
	|";
	локОлеДБКоманда.Выполнить(текстЗапроса);
	// Таблица подчиненных
	текстЗапроса="
	| SELECT
	|
	|Подчиненные.childid
	|
	|FROM 1SCRDOC as Подчиненные
	|WHERE Подчиненные.childid+Подчиненные.mdid+Подчиненные.parentval='123456789'
	|";
	локОлеДБКоманда.Выполнить(текстЗапроса);

	текстЗапроса="
	| SELECT
	|
	|Жур.iddoc
	|
	|FROM  1SJOURN  as жур
	|WHERE Жур.iddoc='123456789'
	|";
	локОлеДБКоманда.Выполнить(текстЗапроса);
/// Здесь можно открыть еще таблицы бухгалтерии - если кому нужно

	ВремяКонецЗапроса=_GetPerformanceCounter();
	ВремяЗапроса=ВремяКонецЗапроса-ВремяНачалоЗапроса;
	локОлеДБКоманда.Выполнить("EXECSCRIPT('SET REPROCESS TO 0 SECONDS')");
	//Сообщить("Запрос длился "+(ВремяЗапроса/1000)+"с");

КонецПроцедуры 

где

Функция Таблицы)
	5884+sp5885+sp5886
	ИмяПоляНач="$"+ПсевдонимТаблицы+"."+ИмяПоля;
	Если Тип="Справочник" Тогда
		ПеременнаяПоля=ИмяПоляНач;
	ИначеЕсли  Тип="Документ"  Тогда
	   ПеременнаяПоля=ИмяПоляНач;
	ИначеЕсли  Тип="Перечисление"  Тогда
	   ПеременнаяПоля=ИмяПоляНач;
	ИначеЕсли  Тип="Строка"  Тогда
	   ПеременнаяПоля=ИмяПоляНач;
	ИначеЕсли  Тип="Неопределенный"  Тогда
	   ПеременнаяПоля=ИмяПоляНач;
	ИначеЕсли  Тип="Дата"  Тогда
	   ПеременнаяПоля="DTOS("+ИмяПоляНач+")";
	ИначеЕсли  Тип="Число"  Тогда
	   ПеременнаяПоля="STR("+ИмяПоляНач+","+Строка(Длина+1)+","+Строка(Точность)+")";

	КонецЕсли;
	Возврат ПеременнаяПоля;
КонецФункции    

Инициализация занимает 0.05 сек
Все. Можно пользоваться любыми запросами созданными на основании глОлеДБ

kiruha писал(а) 13. Марта 2008 :: 03:42:

Если тебе нравится ставить эксперименты на собственной заднице - ради бога. Никто не запрещает (может, ты удовольствие от ощущений получаешь). Но не надо преподносить ЭТО как решение проблемы блокировок. Потому что из-за тебя кто-то может здорово попасть.

Я считаю, что для каждого логического юнита выборки данных нужно делать передподключение к БД, иначе есть риск получения устаревших данных. Юнитом считаю, например, выборку данных при проведении документа или процедуру формирования отчета.

Я уже писал, как наталкивался на проблему кеширования. Проводим один документ, делаем запрос. В этом же сеансе 1С проводим еще документ. Делаем второй, точно такой же, запрос. Получаем старые данные. Если перед выполнением второго запроса вставить переподключение - все работает. Повторяемость 100%. Однако, когда пытался выделить минимальный код, демонстрирующий проблему, то не получилось. Тем не менее, считаю, что проблема кеширования есть - просто достаточно редко проявляется.

В общем, кто как хочет. Я предупредил - чур, в случае проблем с задницей - претензии мне не предъявлять Впрочем, вы знаете КОМУ их нужно будет предъявлять в случае использования предложенного здесь решения

Nick писал(а) 13. Марта 2008 :: 04:17:

Совершенно согласен. Мой вариант - тоже фигня ИМХО, немного менее страшная, но тем не менее В общем, на СКЛ переходить надо, ничего не попишешь.

kiruha писал(а) 13. Марта 2008 :: 04:35:

Чукча писатель? Я совершенно ясно сказал, что я считаю некорректным.

Uzhast писал(а) 13. Марта 2008 :: 04:37:


глобальную переменную глОЛЕДБ использую год. Проблем не наблюдалось.
И вероятно не я один.

Uzhast писал(а) 13. Марта 2008 :: 05:52:


1.Наверно не менее 100 000 пользователей в мире каждый день работают с FoxPro и не подозревают -
что оказывается для того чтобы данные были не кривые - им нужно все время прерывать соединение с базой,
а чтобы работал многопользовательский режим - нужно пропатчить драйвер.

2. Где то на форуме (itland?) встречалось упоминание о проблеме с "грязными" данными. Не смог сейчас найти.
Там была рекомендация закрывать команду.
У меня везде после запроса Цитата:
Проблем нет.

3.Uzhast, я хоть где то написал, что ты - нехороший человек?
И за любое замечание я только благодарен .

kiruha писал(а) 13. Марта 2008 :: 03:42:


А вот с этой штукой я бы аккуратнее бы обращался...
Попытаетесь вы, что то писать, запись заблокирована, что будет, будем стучаться в эту запись 60 сек. А дальше пользователь, который захватил эту запись, ее освобождает, и Вы туда преспокойно пишите свои данные. А Если он там свои записал? Что будет? В свое время на FOX-е попал на эту бяку. В системе не удалял физически удаленные записи, использовал их повторно. Вот и получилось: Первый пользователь захватил, записал, снял блокировку. А второй в момент захвата записи первым, тоже пришел к этой записи,  и ждал когда ее освободят. Результат был плачевный...

nicolas писал(а) 13. Марта 2008 :: 12:19:


Потому что, что-то с блокировками было  не то, но вообщем эта тема не имеет значения -
в процедуре не используется никакой записи, лично я вообще не использую записи через FoxPro в реальном
времени, и в конце процедуры стоит сброс этого параметра на 20 сек - можете выставить 0,
от этого ничего не изменится.

kiruha писал(а) 13. Марта 2008 :: 13:48:

Неее, ты мне тест прокомментируй. Ты ж всех тут уверял, что все абсолютно безопасно, про сто тыщ леммингов рассказывал, которые постоянно получают "некривые" данные. SET SQLBUFFERING приплел еще... И вообще жду благодарности за избавление твоей задницы от последствий от вставляния этого твоего кода в твою конфу