Alexbootch, ну нельзя использовать rowid в качестве идентификатора записи. Зачем копать себе яму на будущее вместо того, чтобы подумать заранее?

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

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

Dilma, не все можно упихать в десяток компонентов, а выкладывать прогу из 1500 тысяч элементов, просто бессмысленно. Я еще подумаю над собственной реализацией, удалось же самому реализовать некоторые пояснения сего топика. А смысл задачи очень простой -- есть N каналов с набором параметров (строки таблицы), их надо последовательно загрузить в динамические мультики, актвировав в последних определенные части схемы, но для редакции они должны в такой же последовательности выводиться на экран. Получается так -- если в экранной таблице это 2-я строка, то в дальнейшем за этот канал будет отвечать именно 2-й динамический мультик. Мультики имеют последовательную нумерацию на единицу больше предыдущего, вот откуда и взялось это

nesco, вот с этого и следовало начинать. Собственно единственно правильное тут решение, это паралленьное хранение ##handle где-нибудь в массиве, благодяря которому всегда будет можно по индексу получить Handle мультика, затем выполнить ##HSelect и далее уже через primary key(сохраненный в каждом мультике для своей записи) обращаться к базе. Надежное и достаточно простое решение.

Dilma, оригинально. Но как-либо упрощенно это нельзя на пвльцах показать? Я не понял момента с ##handle, они разве не меняются при каждом запуске и создании N количества мультиков?и как это осуществить тоже не понятно.

насколько я понял задачу мультик создается один раз для каждой записи из базы. ак вот ему при создание нужно передавать в качестве параметра(например в потоке точки ##add) primary key из базы и сохранять скажем в memory.

##handle при каждом запуске меняются, но тут это не важно. Важно то, что при таком решение нет привязки к конкретному индексу.

code_1915.txt

в примере: элемент For это цикл получения записей из таблицы, элемент Random это получение primary key для записи. При выборе пункта списка получаем по индексу уникальный ID записи и далее делаем свои дела. Очевидно, что при синхронном удаление строки из listbox, MultiElementEx и массива ничего пересчитывать нигде не нужно и при этом схема будет совершенно коректно работать.

Dilma, я рассмотрел твою схему, действительно оригинальное решение, но у нее есть один недостаток -- быстродействие. Я отказался от выполнения каких-либо циклических запросов внутри мультика и по точке ##add уже передаю считанные основные параметры, сохраняя их в MT_MultiMem внутри каждого мультика для каждого канала (остался у меня, правда, один запрос в мультиках, но делается он только по ##add). Каналы считываются из базы все, в той последовательности, как они там идут, параллельно сортируясь по параметру Status, означающем включение/выключение канала (вот запрос, выполняющий оисанные действия -- SELECT idx, Port, Baud, Color, Lines FROM Channels WHERE Status = 1;. В данном случае ##add будет столько, сколько будет выборок из базы. Для определения их возможного количества выполняется перед предыдущем запросом запрос -- SELECT COUNT (Status) FROM Channels WHERE Status = 1;. Сравнивая количество созданных мультиков по ##count с полученным количеством выборок, я определяю конец цикла создания и начало перехода на цикл опроса. Вот схемка, поясняющая этот метод code_1917.txt), и по-этому мультиков тоже получается заранее неопределенное количество, но в таком случае в память не грузятся "мертвые души", и никакой привязки к Id. Сложность возникла как раз не в организации мультиков, это оказалось для меня самым простым, а именно в физической сортировки строк в самой базе, особенно после удаления, когда индексы теряют заданную последовательность, и она не соответствует последовательности в экранной таблице, ну например: после удалени и перечитывания базы в экранной таблице строки нумеруюются как 0,1,2,3,4,5, а в базе -- 1,2,3,5,6,7. И как дальше работать -- выбираешь 0-ю строку -- ей соответствует 0+1 Id базы, а выбираешь 4-ю строку -- ей уже соответствует 4+2 Id базы, а вот rowid, если его упорядочить (по Vacuum, как рекомендут Alexbotch) как раз и будет 4+1. Какой выход ты можешь посоветовать в данной ситуации, чтобы уйти от rowid.

nesco, на счет быстродействия не понял. По поводу индексов тоже - предложенное решение разве не является решением? Еще раз суть идеи: нельзя запросы от программы к базе реализовывать на каких бы то ни было номерах. Даже больше - нельзя идентифицировать запрос по полю, от изменения которого мы не застрахованы. В приведенном примере как раз и показано, что правильнее и надежнее делать такую ассоциацию в самой программе(Index в листбоксе -> ##Handle контейнера), где мы имеем полный контроль.

Dilma, похоже, мы просто не понимаем друг друга. Вот первое Непонятно к чему это относится. В моей схеме запросы к базе и загон параметров в мультики происходит только один раз -- при создании мультика, все, дальше никаких изменений параметров в мультике не происходит, за исключением связи с внешними данными, никак не связанными с загружаемой базой. Ну изменится основной параметр сортировки до момента загрузки, ну и что -- мультик будет, либо создан, либо нет. Опрос мультиков происходит обычным счетчиком и тоже не связан с базой, только при создании мультиков. А разве нельзя использовать обычный ##select с индексом мультика, который выдается счетчиком, параметры то уже внутри?
Тоже не могу понять, почему нельзя использовать какие-либо последовательности индексов для вывода на экран и перестановки строк. Везде в примерах применяют индексы и последовательные значения, тут же получается совсем наооборот. Хорошо, а если больше привязаться не к чему, только к индексу, все остальные парметры разные, и что теперь делать?

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


в каких примерах?


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

Конкретный вопрос: что на этот раз не удается сделать, если
- правильная перестановка записей была описана
- правильная идентификация записей была приведена
- корректное удаление без пересчета было дано
- переход от индекса записи в элементе отображения к уникальному ключу записи был дан

Кем дано? Alexbotch применяет rowid, а мы говорили об его анулировании. У меня все и так неплохо работает, но разговор был о несостоятельности методов применения абсолютных индексов строк, вот я и решил отойти от применения rowid и столкнулся с тем, что привязаться то не к чему, особенно, после удаления строки, когда получаются индексные разрывы.
Мне нужно соответствие индексов табличного экранного вывода и физического расположения строк, все -- остальное уже сделано. Те, если я выбираю строку экранной таблицы с индексом 3, то она должна быть в базе с индексом 4 и никакой другой.

[size=-2]------ Добавлено в 14:16

Dilma, ну если в этом случае, то я не спорю, да и не собираюсь спорить. Но мне и не обязателен был случай, когда параметры нужно считывать в каждой текущей схеме. У меня похожий вариант был в начале, и я добился результата, когда в память не грузятся "мертвые души" и также не используются индексы. Меня больше волнует режим редактирования, чем режим создания, опроса и удаления мультиков. Ну например: как ты делаешь перемещение иконок по палитре, они же могут ездить вверх и вниз, это сохраняется в файле базы или в файле конфигурации?

точно так же, ка кописывал tsdima в этом топике на примере поля MySort. В базе данных hiasm оно завыется несколько иначе - pos.

PS: вот если бы в elements.db запросы к базе проходили через идентификацию по индексу(т.е. номеру элемента в палитре) то даже представить сложно, в какую бы кашу превратилась таблица при одновременном перемещение/удаление/вставки элементов палитры из двух экземпляров среды. Скажем алгоритм с использование VACUM при удаление одного и тоже эелемента из двух копий среды привел бы на самом деле к удалению двух элементов, о чем юзер бы узнал только при следующем запуске...