Просто результат нажатия разный (при разрыве значений ключа).
Второй раз вижу этот оборот (в прошлый раз было сформулировано "до разрыва в порядке записей") - и всё пытаюсь перевести на привычный язык... "Я понял - это намёк, я всё ловлю на лету... но не понятно, что ты имела в виду..."
Я так понимаю, до идеи "широкая таблица и куча узких запросов" руки еще не дошли? Тут ведь какая петрушка получится - долго искать "нужную запись" не пришлось бы, она всего одна будет: или она есть и тогда она всегда будет под рукой, или её уже нет и искать её бесполезно.
Привязывать к "правильной СУБД" цели не ставил, да и не задумывался. Может это и необходимо.
Замерщик, прямо на объекте, через мобильный (или местный) интернет вводит параметры объекта с планшета, ноутбука, хозяйского компьютера... При этом работает с реальными ценами, которые выставил на сегодня головной офис... При этом маркитантки в офисе могут видеть, как рождается новый заказ и оперативно предпринимать некоторые телодвижения, которые в идеале ускорят оформление договора и получение гонорара. Подумай на досуге... Но имей в виду - как минимум двое из четырех программистов, которые за шесть лет делали подходы к этой задаче, тоже об этом думали... И где они теперь?.. Так что думай осторожненько.
Тем не менее - сколько же записей (или мБ) информации "тянет" HSQLDB? Ответ где-то был, да не найду сейчас.
Если грубо, на пальцах - то приблизительно половина доступной оперативной памяти на конкретной железяке: чем тачка круче, тем больше данных без сбоев-геморроев будет храниться и обрабатываться в одной и той же Двери.odb
Как, всё-таки, осуществить переход к нужной записи? Да и сохранение только что заведённого не работает.
Вставлял строку "oForm.updateRow()" - ругается что не определена переменная (я понял что строка (запись) должна быть определена как переменная), но все мои Dim не сработали.
Не может быть! Говоришь, что Великий Метод Научного Тыка перестал работать? Не верю! (с) Станиславский
