SQL запрос к DBF базе #434036

Коллеги, есть проблема. База "Рарус - магазин", однопользовательский вариант, пользователи работают в монопольном режиме. Было бы занятно использовать в этой базе прямые запросы, с использованием 1c++. Пробовал Visual FoxPro Ole DB Driver 9.0, но у него есть ограничения - не работает в монопольном режиме. В связи с этим 2 вопроса: 1. Можно ли вообще с помощью другого драйвера делать эти запросы, находясь в 1С монопольно? 2. Если да, то можно про этот драйвер подробнее ?

то есть спец форум

1sqlite

Искал там инфу но не нашел. Попробую еще раз

Последняя правильная версия где-то на 44ой странице выложена.

небольшая подмена dbeng32.dll и всё прекрасно работает сто лет в обед и на фоксовом провайдере.. если что.

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

а можно подробнее ?

спасибо всем надо убежать, в понедельник если непонятно будет апну...

А поподробнее. Я знаю патчат фоксовую длл vfpoledb.dll, убирают блокировку. Но это не спасает от монопольного режима

там про монопольный режим не увидел

Вот и я о том же. См

Hogik  по просьбе трудящихся постарался... на инфостарте есть решение этой проблемы..

ищите ветки этого автора,когда сайт починят.

Хотя, могу и тут кинуть.

Кидай тут. А то там уже таймер обратного отсчета убрали. Видно support уже и не надеяться, что он подниметься

Решение проблемы выполнения прямых запросов в монопольном режиме и исправление ошибки “CodeBase –56” для DBFной версии 1С:Предприятие 7.7. Компонента перехватывает все функции DBEng32.dll. В функциях открытия таблиц выполняет проверку режима запуска сессии 1С. Если 1С запускается в монопольном режиме, то таблицы открываются в эксклюзивном режиме, закрываются и открываются в разделяемом режиме. Для функций, требующих эксклюзивного доступа к таблицам (реиндексация, упаковка, удаление всех записей), таблица закрывается, открывается в эксклюзивном режиме, выполняется “эксклюзивная функция”, закрывается и открывается в разделяемом режиме. Для рабочих таблиц, используемых в штатных запросах, режим открытия не изменяется. (c)

DBEng32 (8.0.0.7, Share) – выполнение прямых запросов в монопольном режиме для DBFной версии 1С:Предприятие 7.7 в среде 1С++

вот это оно и есть... качаем это файло... в папке BIN переименовываем в DbEng32.dll в DBEng33.dll и кладем туда скаченное файло. Наслаждаемся.

т.е. просто подмена длл и все, больше специально ничего делать не надо?

да.

Но ведь по сути это просто получается обман 1Ски. Обычная работа так и идет в разделяемом режиме, просто 1С считает, что в монопольном. А реальной выгоды, которая бывает от настоящего запуска в монополе - нетути.

а может наоборот? 1С считает что работа идёт не в монопольно мрежиме хотя на самом деле режим монопольный. или я ошибаюс?

как это "нетути"? мне например надо чтобы при написании и отладке программы я мог по Ф11 из конфигуратора тсратовать базу и пользоваться быстрыми запросами

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

"у меня уже давно настроено стартовать по F11 не в монополе" - рецептом не поделишься?

+ К тому же фокс сортирует не так, как сама 1С, что иногда чревато.

Сохранить в bin/config/scripts Назначить на нужные кнопки. $NAME Запуск 1С var bNeedRun = 0 function Run1C(mono) {    var shell = new ActiveXObject('WScript.Shell')    if(MetaData.Modified)    {            {        }    } }    if(bNeedRun)    } }

Спасибо!

ээх..на наших серверах не особо заметил падения производительности.. Надо бы потестить как-нить. да скачай ты наконец все скрипты к опенконфу в репозитарии.. :)

Вот подтверждение для Создаем справочник Новый1, для простоты - длина кода 0, длина наименования - 25. Заполняем элементами со следующими названиями: Теперь используем непобедимый фокс. Вариант 1, заставим фокс юзать индекс UPPER(DESCR): Получаем три элемента: A lat, B lat, N lat O lat и P lat не попали в выборку, хотя они меньше, чем Z Ну, тогда попробуем запрос без использования фоксом индекса, чего на практике следует избегать. Вариант 2: Теперь получим 5 записей: A lat, B lat, N lat, O lat, P lat Вроде бы как бы и верно. Теперь тот же запрос через 1sqlite: Вариант 3: Получаем в ответ 6 записей: A lat, B lat, N lat, № рус, O lat, P lat Кто прав? Открываем форму списка справочника, включаем сортировку по наименованию, и видим, что с точки зрения 1С прав все-таки запрос 1sqlite. Оба фоксовых запроса вернули неверный результат.

Все? А мне худо не станет? А ссылка? И что там есть полезного?

+ А вот самый ужас. На тех же данных запрос через фокс с использованием индекса с проверкой на равенство (что часто применяется в джойнах): Вообще не нашел существующую запись. То есть если раньше считалось, что отличия в порядке сортировки индексов в cdx файлах между 1С и фоксом влияют только при записи (фокс портит 1Сные индексы), то теперь понятно, что это может привести к проблемам и при чтении.

мс фокс тим - казлы.

А вот тут надо еще подумать кто казлы. Зачем 1С для codepage 1251 сделала какую-то свою сортировку, отличную от общепринятой?

может быть, чтобы набор символов в таблице был сплошным куском без дыр?

Ага, это очень "без дыр" - засунуть символ '№' между 'N' и 'O' И ладно бы только его, там таких приколов еще много...

Вот сделай для пустого справочника: А потом посмотри как этот справочник 1С отсортирует в форме списка. А выгрузи все в ТЗ, в ней отсортируй по наименованию - и сравни с формой списка - будешь удивлен.

не, спасибо, я с фоксом наигрался, когда писал oledb, теперь меня проблемы фокса могут волновать только в страшном сне :)

Ну, наверное тогда для у тебя есть свои основания :)

кстати, ты как-то светил скрин, в котором у тебя было флотинг окно. Можешь в нескольких предложениях рассказать как ты это делал? :)

В двух словах не расписать. Давай на 1cpp.ru пересечемся.

"...запуск в монополе используют для массового перепроведения..." Скорость выполнения операций в транзакции для разделенного режима, практически, равна скорости выполнения транзакций в монопольном режиме. А скорость чтения данных в локальном режиме (вне транзакции), если запущена одна сессия 1Са, практически, равна скорости чтения в монопольном режиме. Мы, вроде, это уже выяснили... ;-)

Попробуйте поставить "Collating Sequence=RUSSIAN".

так вроде в индекс фокс никогда не попадет. kiruha на 1cpp.ru очень плотно исследовал эту тему.

да и см. (35,38) у 1С своя кодировка, непохожая ни на кого! ;)

Попадает иногда. ;-) Кодировка, действительно, у 1С "своя" - в движке одна, а в оперативной памяти другая. ;-) Но "странный" порядок сортировки в таблицах БД не от 1Са, а от "Sequiter Inc.". Если сравнить DBFные системы: родной 1Совский CodeBase, CodeBase 6.5, Advantage 8.1/9.1, то у них у всех разный порядок сортировки. И у всех порядок не совпадает с порядком сортировки/сравнения символов в оперативной памяти 1Са. Но если говорить о моем предложении из , то оно касается порядка символа "№". И по моим воспоминаниям значение "MACHINE" в FoxPro-подобных системах указывает на двоичное сравнение символов - без преобразования по таблице перекодировки. Что полностью укладывается в проверки от orefkov. Т.е. в индексах данные лежат в одном порядке, а FoxPro предполагает, что в индексах ключи лежат в другом (машинном) порядке и поэтому отрубает выборку раньше времени.  При выборке без индекса тоже все логично - так и должно быть (по двоичному значению). P.S. В Advantage символ "№" стоит между символами "N" и "O", а в CodeBase 6.5 - не стоит на этом месте. P.P.S. Интересно, а в MS SQLной версии 1Са порядок в индексах совпадает с порядком сортировки/сравнения символов в оперативной памяти?

Странно. Почему в сообщении начало текста выделилось желтым цветом? Я этого не хотел... ;-)

А что значит "иногда" попадает в индекс? Я говорил к тому, что ты предлагаешь поставить "Collating Sequence=RUSSIAN" в результате чего мы потеряем главный плюс прямых запросов - скорость, т.к. больше не попадем в индекс и при каждом запросе будет сканироваться вся табличка данных.

1) Под "иногда" я понимаю пример теста от orefkov. Результат выборки то у него разный. Т.е., кажись, попал в индексы. ;-) Т.е. потеря данных, начиная с символа "№", связана с тем, что индексы - используются. 2) Я не знал, что установка "RUSSIAN" ломает попадание в индексы. P.S. Наше разночтение сообщений данной темы связано с тем, что я не понял Вашего текста из сообщения "так вроде в индекс фокс никогда не попадет". Т.е., что слово "так" относится именно к моему предложению установить "RUSSIAN". Т.к. в голове у меня была информация по моему сообщению. Извините, виноват...

да много чего есть полезного...

Люди, спасибо за инфу, попробую bkend32 подложить