kiruha
Нет, случай маловероятный, но не экзотический.
Неуникальный ID в уникальном поле - это нарушение идеологии системы, имеем полное право считать такую ситуацию недопустимой, а замещение записей - ситуация штатная, прогнозируемая.

Uzhast
Цитата:

То же самое касается GetRowValue и преобразования CDataRow в CValue.
Предположим, мы стоим на строке, которую удаляют и замещают другой на том же месте.
В тот момент, когда мы нажмем Enter для ключа "x y z ID" мы получим ошибку позиционирования (если ID стал другим и не возродился в другом месте).
Для ключа "x y z rec_no" мы найдем строку (если x y z остались теми же), которая будет совпадать по ключу, но не будет соответствовать ожиданию пользователя.

P.S.
Конечно, согласен, что ситуация редкая.
Это примерно как с нюансами нехватки памяти, или обработки исключений.
Более того, если даже что-то произойдет, это будет практически неповторяемо; скорее всего, пользователь даже не поймет, что и откуда прилетело.

Засим умолкаю...
В мою задачу совсем не входит деморализовать отличные идеи быстрого позиционирования в DBF.
Мне просто приятно поговорить с умными людьми

...
Но если будет нормальный выбор, лучше делать надежное решение.

orefkov писал(а) 20. Октября 2007 :: 04:52:

1. Вот так можно уронить:

select * from Номенклатура
where PARENTID_ISFOLDER_DESCR = 1
order by PARENTID_ISFOLDER_DESCR


2. case sensitivity для русских названий индексов

select * from Номенклатура
order by PARENTID_ISFOLDER_Артикул -- работает

select * from Номенклатура
order by PARENTID_ISFOLDER_АртикуЛ -- нет


3. Не возникло взаимопонимания при установке фильтров

select * from Номенклатура
where parentid = '     0   '

Дает пустой запрос, хотя корневые элементы, конечно, есть.

При этом в плане запроса

5	VFilter	0	49	SC84.PCODE;?0;
 

имя индекса подходящее, но непонятно что означает ?0
в число преобразует?

4. Вот такой запрос

select * from Номенклатура
where parentid = '     0   '
and isfolder = 1
and descr > 'У'

в плане запроса дает

6	VFilter	0	53	SC84.PCODE;?0;1;
7	VColumn	0	3
8	String8	0	0	У
9	Le	353	52	collseq(BINARY)
 

верно ли это (ожидаемо было бы получить индекс PDESCR)

Теперь Uzhast.
Цитата:


Ты этот свой "простой" алгоритм кроме своей головы еще гденить пробовал тестить?
У тебя п.2 и п.3 противоречят друг-другу.
Если ты используешь индекс для упорядочивания, то перейти по физическому номеру записи невозможно.
Кроме как full-scan'ом.
Так-что возможный алгоритм мог бы быть такой (для случая выборки следующих строк) :
1. Делаем index seek по ключу.
2. Сканируем по индексу дальше, ища запись с нужным физическим номером.
3. Получаем следующие записи.

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

Во-вторых, ТП работает не так, как ты себе представляешь - оно не просит
провайдера "получи М строк от текущей записи".
Оно просит "получи первые М строк с ключом БОЛЬШИМ, чем вот этот сохраненный ключ"
Так вот в этом случае, если бы я точно был уверен, что одинаковые ключи в индексе
расположены СТРОГО по порядку номеров физических записей, алгоритм был бы таким:
1. Делаем index seek по переданному ключу.
2. Двигаемся по индексу далее, пока (номер записи меньше переданного и ключ не больше переданного).
3. Как только это условие не выполняется, получаем М строк.

Вот поэтому я и спрашивал, упорядочиваются ли дублирующиеся ключи в индексе ещё и
по физическим номерам записей.

Цитата:


Ща я тебе покажу, какая это гадость - курсоры.
Проведем экперимент:
1. Открываем две копии 1С с одной базой, хоть дбф, хоть sql.
2. Открываем в ней форму списка большого справочника.
3. В обоих базах ставим время автообновления 99, и встаем на один и тот же элемент справочника
   примерно в середине списка, где-то например, на букве "К".
4. В одной копии меняем название элемента, например, первую букву заменяем на "П".
5. В другой - пытаемся походить вверх/вниз от текущего элемента. Внимательно наблюдаем
   за интересными артефактами.
6. Закроем/откроем справочник.
7. Опять встаем на один и тот-же элемент.
8. В одной программе переносим элемент в другую группу.
9. В другой пытаемся  походить вверх/вниз от текущего элемента. И не можем этого сделать.

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

А в ТП с ODBC-поставщиком данных такой хрени не происходит.
И насчет "лишние тормоза на ровном месте" хотелось бы, чтобы ты свое мнение
подтвердил конкретными цифрами и тестами. Если конечно сможешь написать ODBC-поставщика
на серверных курсорах.

А "проскок" N строк в текущей реализации ODBC-поставщика очень даже можно сделать.

select max(key) from (select top N key from lalala where key > storedkey order by key) topNkeys
либо
select top 1 key from (select top N key from lalala where key > storedkey order by key) topNkeys order by key desc

Вечером постараюсь выложить тест с цифрами.
Получается что для связка 1с sql +
виртуальная таблица sqlite работает значительно быстрее чем скопированная в память родная таблица sqlite на реальном большом справочнике Клиенты.
Очень неожиданный положительный результат.
Для 1с dbf такого нет.( т.е. родная sqlite таблица быстрее чем вирт таблица )
Также компонента 1.4 на родной sqlite таблице работает чуть быстрее
чем с версией 1.0 1csqlite.dll, если надо то тоже выложу эти цифры.

orefkov писал(а) 26. Октября 2007 :: 06:12:

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

Использование, например, ключа PARENTID,ISFOLDER,DESCR,ID (ID - это добивание ключа до уникального)
(выборка top n по возрастанию, т.е. строки, больше значения полного ключа)

0. Делаем index seek по переданному неполному ключу
1. Если такого ключа нет, Goto 6
2. Выбираем все записи по текущему ключу
3. Сортируем по ID
4. Запоминаем к возврату строку с upper_bound(id) по end
5. Если найдено достаточно строк, возвращаем результат (n строк)
6. Перемещаемся к следующему неполному ключу (идем по индексу)
7. Выбираем все значения ключа
8. Сортируем по ID
9. Запоминаем к возврату все строки
10. Goto 5

Конечно, тут есть приличный overhead, но алгоритм безопасен.

Uzhast писал(а) 26. Октября 2007 :: 08:27:

ТП 100% не знает, поэтому его так легко обмануть.
Суть в привязке CDataRow, она может быть привязана к физической строке - и тогда быть беде, либо к логической, т.е. некому абстрактному местоположению в пространстве строк (что сейчас и сделано для ODBC провайдера).

Ну, собственно, теоретическая база у нас уже распухла
Будет интереснее пообсуждать уже проблемы реальных моделей.

Модель с физической привязкой, кстати, уже есть.
Это VT провайдер.

Uzhast писал(а) 26. Октября 2007 :: 08:27:

Ню-ню.
Если ты думаешь, что написав
set order to idd
goto 100
фокс тебе моментом найдет запись, не применив full scan по индексу, то эт вряд ли.
Вроде такой большой, а в сказки веришь
А матчасть я-то изучал уже, вплоть до структуры cdx-файла.
И прямо тебе скажу, что информации, что бы по номеру записи найти узел в дереве индекса, соответствующий этой записи, с тем чтобы двинуться от этого узла дальше, в нем нет. Кроме, естественно, полного обхода дерева индекса с корня до нахождения листа с нужным номером записи.
Возможно, это одна из причин 30-40% загрузки проца в твоем провайдере.

Uzhast писал(а) 26. Октября 2007 :: 08:52:

Лукаваишь, ой лукавишь.
На варианте, когда из-за изменения родителя одним юзером другой даже сдвинутся с места с записи не может, ты решил не заострять внимания.
Да и с этими артефактами - видимо тебе юзеры не разу не звонили - "Что за хрень у меня в списке творится? Иду по справочнику, а вместо одного элемента другие появляются. Стою на "А", перехожу почему-то на "Я".
И твою точку зрения, что это нормально, они бы тебе запихали глубоко.
Согласись, это не нормально, когда изменения, сделанные одним юзером, сбивают выборку у другого.
Человек вправе ожидать, что после "А" будет идти "Б", чего бы другие там в базе не творили.

Uzhast писал(а) 26. Октября 2007 :: 08:52:

Скажу тебе по секрету, что когда работаешь с SQL-сервером, для любых действий надо делать запрос.
И зря ты думаешь, что такой запрос напряжет сервер. Он, сука, умный, и поймет, что от него хотят всего-лишь seek and skip.