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.