Переключение на Главную Страницу Страницы: 1 ОтправитьПечать
Обычная тема OLEDBData: фича или глюк? (число прочтений - 4189 )
maljaev
Senior Member
****
Отсутствует


Классический секс с 1С
надоел. Хочется изврата...

Сообщений: 405
Местоположение: Нижний Новгород
Зарегистрирован: 19. Октября 2006
Пол: Мужской
OLEDBData: фича или глюк?
31. Июля 2007 :: 23:34
Печать  
Настраиваю у клиента обмен с филиалами с использованием части функционала УРИБ. Ну, разумеется, юзаю по полной 1SUPDTS.DBF: и изменения объектов из нее читаю, и пакеты присваиваю, и записи удаляю. Все гут, индексы поддерживаются, счастье есть Улыбка. И вдруг нахожу в своей программе (как я думал) ошибку, искал ее часов 5, алгоритм шерстил десятки раз, найти никак не мог. В конце концов после долгих мучений вышел на источник. Смысл в том, что после создания/изменения любого объекта, зарегистрированого в УРИБ для обмена и автоотслеживания изменений, создается запись в 1SUPDTS. Запись действительно создается и я ее даже вижу с помощью CDBF (вьюер), но OLEDB видит ее не сразу. Отсюда и проблемы.

Выявил примерно так:

Код
Выбрать все
// где-то в начале модуля
База = СоздатьОбъект("OLEDBData");
База.Connect("Provider=VFPOLEDB.1;Deleted=No;Data Source=" + КаталогИБ() + ";Mode=ReadWrite;Extended Properties="""";User ID="""";Password="""";Mask Password=False;Collating Sequence=MACHINE;DSN=""""");
Команда = База.СоздатьКоманду();
....
// где-то в середине модуля
Сообщить(Команда.ВыполнитьИнструкцию("SELECT * FROM 1SUPDTS").КоличествоСтрок()); // пишет 0 - пока изменений еще не было
Объект=ЗагрузитьОбъект(тзДанныеЗагрузки); // создается (или изменяется) элемент справочника или дока
Сообщить(Команда.ВыполнитьИнструкцию("SELECT * FROM 1SUPDTS").КоличествоСтрок()); // опять пишет 0, хотя долно быть 1 - я эту запись физически вьюером вижу даже
 



Был в шоке. Выкрутился на данный момент постоянным подключением/отключением к базе после каждой инструкции:

Код
Выбрать все
// где-то в начале модуля
Процедура СКЛВыполнить(ТекстИнструкции)
	База = СоздатьОбъект("OLEDBData");
	База.Connect("Provider=VFPOLEDB.1;Deleted=No;Data Source=" + КаталогИБ() + ";Mode=ReadWrite;Extended Properties="""";User ID="""";Password="""";Mask Password=False;Collating Sequence=MACHINE;DSN=""""");
	Команда = База.СоздатьКоманду();
	Команда.Выполнить(ТекстИнструкции);
	Команда = "";
	База.Закрыть();
КонецПроцедуры

Функция СКЛВыполнитьИнструкцию(ТекстИнструкции)
	База = СоздатьОбъект("OLEDBData");
	База.Connect("Provider=VFPOLEDB.1;Deleted=No;Data Source=" + КаталогИБ() + ";Mode=ReadWrite;Extended Properties="""";User ID="""";Password="""";Mask Password=False;Collating Sequence=MACHINE;DSN=""""");
	Команда = База.СоздатьКоманду();
	Результат = Команда.ВыполнитьИнструкцию(ТекстИнструкции);
	Команда = "";
	База.Закрыть();
	Возврат Результат;
КонецФункции
....
// где-то в середине модуля
Сообщить(СклВыполнитьИнструкцию("SELECT * FROM 1SUPDTS").КоличествоСтрок()); // пишет 0 - пока изменений еще не было
Объект=ЗагрузитьОбъект(тзДанныеЗагрузки); // создается (или изменяется) элемент справочника или дока
Сообщить(СклВыполнитьИнструкцию("SELECT * FROM 1SUPDTS").КоличествоСтрок()); // вот теперь пишет правильно - 1
 



Таким образом я несколько замедлил алгоритм, но в масштабах обработки несущественно. Остался вопрос: в чем причина: (1) я что-то не так делаю (2) это фича OLEDB или алгоритмов блокировки 1С (3) это глюк?
  
Наверх
 
IP записан
 
ev-kov
God Member
*****
Отсутствует



Сообщений: 694
Зарегистрирован: 27. Декабря 2006
Пол: Мужской
Re: OLEDBData: фича или глюк?
Ответ #1 - 01. Августа 2007 :: 01:30
Печать  
Может у драйвера Foxpro есть какой то механизм кеширования на чтение ? Вьюер при этом использует прямой доступ без использования кэша - отсюда скорее всего и разное видят в dbf-ке.

ЗЫ: действительно, ты поимел теперь неклассический (извращенный) секс с 1С  Смех
  

Информация - то, что снижает неопределенность в какой-либо области и очень важно не ошибиться областью в наш информационный век!
Наверх
 
IP записан
 
Nick
God Member
*****
Отсутствует



Сообщений: 1599
Местоположение: г.Новокузнецк
Зарегистрирован: 21. Февраля 2007
Пол: Мужской
Re: OLEDBData: фича или глюк?
Ответ #2 - 01. Августа 2007 :: 02:07
Печать  
Может это тебе както поможет:

If you want to protect data during updates, use buffers. Visual FoxPro record and table buffering help you protect data update and data maintenance operations on single records and on multiple records of data in multiuser environments. Buffers can automatically test, lock, and release records or tables.

With buffering, you can easily detect and resolve conflicts in data update operations: the current record is copied to a memory or disk location managed by Visual FoxPro. Other users can then still access the original record simultaneously. When you move from the record or try to update the record programmatically, Visual FoxPro attempts to lock the record, verify that no other changes have been made by other users, and then write the changes. After you attempt to update data, you must also resolve conflicts that prevent the changes from being written to the original table.

Choosing a Buffering Method
Before you enable buffering, evaluate the data environment to choose the buffering method and locking options that best suit the editing needs of your application, the record and table types and sizes, how the information is used and updated, and other factors. Once you enable buffering, it remains in effect until you disable buffering or close the table.

Visual FoxPro has two types of buffering: record and table.

To access, modify, and write a single record at a time, choose record buffering.

Record buffering provides appropriate process validation with minimal impact on the data update operations of other users in a multiuser environment.


To buffer the updates to several records, choose table buffering.

Table buffering provides the most effective way to handle several records in one table or child records in a one-to-many relationship.


To provide maximum protection for existing data, use Visual FoxPro transactions.

You can use transactions alone, but you gain additional effectiveness by using transactions as wrappers for record or table buffering commands.



Choosing a Locking Mode
Visual FoxPro provides buffering in two locking modes: pessimistic and optimistic. These choices determine when one or more records are locked, and how and when they're released.

Pessimistic Buffering
Pessimistic buffering prevents other users in a multiuser environment from accessing a particular record or table while you're making changes to it. A pessimistic lock provides the most secure environment for changing individual records but it can slow user operations. This buffering mode is most similar to the standard locking mechanism in previous versions of FoxPro, with the added benefit of built-in data buffering.

Optimistic Buffering
Optimistic buffering is an efficient way to update records because locks are only taken at the time the record is written, thus minimizing the time any single user monopolizes the system in a multiuser environment. When you use record or table buffering on views, Visual FoxPro imposes optimistic locking.

The value of the Buffering property, set with the CURSORSETPROP( ) function, determines the buffering and locking methods.

The following table summarizes valid values for the Buffering property.

To enable  Use this value 
No buffering. The default value.
1

Pessimistic record locks which lock record now, update when pointer moves or upon TABLEUPDATE( ).
2

Optimistic record locks which wait until pointer moves, and then lock and update.
3

Pessimistic table locks which lock record now, update later upon TABLEUPDATE( ).
4

Optimistic table lock which wait until TABLEUPDATE( ), and then lock and update edited records.
5


The default value for Buffering is 1 for tables and 3 for views. If you use buffering to access remote data, the Buffering property is either 3, optimistic row buffering, or 5, optimistic table buffering. For more information on accessing data in remote tables, see How to: Query Multiple Tables and Views.

Note: 
Set MULTILOCKS to ON for all buffering modes above 1.
  
Наверх
ICQ  
IP записан
 
maljaev
Senior Member
****
Отсутствует


Классический секс с 1С
надоел. Хочется изврата...

Сообщений: 405
Местоположение: Нижний Новгород
Зарегистрирован: 19. Октября 2006
Пол: Мужской
Re: OLEDBData: фича или глюк?
Ответ #3 - 01. Августа 2007 :: 02:57
Печать  
Я себе из этой доки (из того что смог прочитать и понять на английском) сделал несколько выводов:

1) Да, Фокс может буферизировать, и в ряде случаев с этим могут быть проблемы.
2) По умолчанию буферизация вроде как выключена.

Если же Фокс вопреки доке сам включает буферизацию, то подскажите: где и как ее выключить? Желательно на пальцах объяснить, т.к. далее SELECT-UPDATE-DELETE-INSERT мои познания в SQL заканчиваются.

ev-kov писал(а) 01. Августа 2007 :: 01:30:
ЗЫ: действительно, ты поимел теперь неклассический (извращенный) секс с 1С  Смех

А у меня в последнее время иначе и не бывает  Улыбка
  
Наверх
 
IP записан
 
kiruha
1c++ power user
Отсутствует



Сообщений: 1249
Зарегистрирован: 11. Апреля 2007
Re: OLEDBData: фича или глюк?
Ответ #4 - 01. Августа 2007 :: 06:50
Печать  
maljaev писал(а) 31. Июля 2007 :: 23:34:
Настраиваю у клиента обмен с филиалами с использованием части функционала УРИБ. Ну, разумеется, юзаю по полной 1SUPDTS.DBF: и изменения объектов из нее читаю, и пакеты присваиваю, и записи удаляю. Все гут, индексы поддерживаются, счастье есть Улыбка.


Изменение индексов, если ты вносишь изменения через FOX- НЕ ПОддерживаются.(остаются старыми)
(Если только ты не используешь какой либо специальный механизм - тогда "в студию" )
То что они не поддерживаются можно увидеть только либо через родные запросы 1С или
через ole - в обоих случаях - точным попаданием в индекс (практически невозможно для OLE).

Но если попал - то не удивляйся отсутствию записей.


  
Наверх
 
IP записан
 
maljaev
Senior Member
****
Отсутствует


Классический секс с 1С
надоел. Хочется изврата...

Сообщений: 405
Местоположение: Нижний Новгород
Зарегистрирован: 19. Октября 2006
Пол: Мужской
Re: OLEDBData: фича или глюк?
Ответ #5 - 01. Августа 2007 :: 07:34
Печать  
kiruha писал(а) 01. Августа 2007 :: 06:50:
maljaev писал(а) 31. Июля 2007 :: 23:34:
Настраиваю у клиента обмен с филиалами с использованием части функционала УРИБ. Ну, разумеется, юзаю по полной 1SUPDTS.DBF: и изменения объектов из нее читаю, и пакеты присваиваю, и записи удаляю. Все гут, индексы поддерживаются, счастье есть Улыбка.


Изменение индексов, если ты вносишь изменения через FOX- НЕ ПОддерживаются.(остаются старыми)
(Если только ты не используешь какой либо специальный механизм - тогда "в студию" )
То что они не поддерживаются можно увидеть только либо через родные запросы 1С или
через ole - в обоих случаях - точным попаданием в индекс (практически невозможно для OLE).

Но если попал - то не удивляйся отсутствию записей.


Не понял. Как же не поддерживаются если в моем случае поддерживаются? Если я удаляю запись через CDBF, то 1С не видит этого, и при изменении объекта создает новую запись. Если я удаляю запись через OLEDB, то 1С прекрасно все видит и при изменении объекта новую запись создает на месте удаленной.
  
Наверх
 
IP записан
 
ev-kov
God Member
*****
Отсутствует



Сообщений: 694
Зарегистрирован: 27. Декабря 2006
Пол: Мужской
Re: OLEDBData: фича или глюк?
Ответ #6 - 01. Августа 2007 :: 10:32
Печать  
maljaev писал(а) 01. Августа 2007 :: 07:34:
Не понял. Как же не поддерживаются если в моем случае поддерживаются? Если я удаляю запись через CDBF, то 1С не видит этого, и при изменении объекта создает новую запись. Если я удаляю запись через OLEDB, то 1С прекрасно все видит и при изменении объекта новую запись создает на месте удаленной.

Посмотри а объект Xbase видит ?
  

Информация - то, что снижает неопределенность в какой-либо области и очень важно не ошибиться областью в наш информационный век!
Наверх
 
IP записан
 
kiruha
1c++ power user
Отсутствует



Сообщений: 1249
Зарегистрирован: 11. Апреля 2007
Re: OLEDBData: фича или глюк?
Ответ #7 - 01. Августа 2007 :: 11:27
Печать  
maljaev писал(а) 01. Августа 2007 :: 07:34:
Как же не поддерживаются если в моем случае поддерживаются? Если я удаляю запись через CDBF, то 1С не видит этого, и при изменении объекта создает новую запись. Если я удаляю запись через OLEDB, то 1С прекрасно все видит и при изменении объекта новую запись создает на месте удаленной.


Да, похоже был не прав.
Провел несколько тестов - вроде при INSERT - Fox все таки обновляет индексы, созданные в 1С.
(а 1С наоборот, индексы созданные в Fox не обновляет).
  
Наверх
 
IP записан
 
Переключение на Главную Страницу Страницы: 1
ОтправитьПечать