|
|
|
|
| |
|
|
| | mdb - нету SQL, вот и мучаюсь а переписывать всё что наваял под него страшно начинать, да никто и не оценит | |
| |
| |
| |
|
|
| | т.е. вопрос в том как скопировать несколько таблиц из одного MDB в другой? | |
| |
| |
| |
|
|
| | как бы да, как из одной неоткрытой - загнать в другую неоткрытую и не дольше ли это по времени чем копировать весь файл по сетке 100 метров.
ну и как вообще к такому решению вопроса относится народ  | |
| |
| |
| |
|
|
| | что значит "не открытую"? сделать связанные таблицы в из обеих баз и запросом на добавление добавлять. Ну или использовать "... IN БАЗА" в запросе.
Было такое решение,данные не изменяемые на этом рабочем месте копировались на локальную машину, пользователи были предупреждены о возможной "не актуальности" данных. данные загружались при старте по кнопке. К решению относился и отношусь отрицательно, но другого ничего не придумал. | |
| |
| |
| |
|
|
| | "не открытая" - база к которой прилинкована клиентская часть.
мне находясь в MDB_№_1 нужно взять таблу из MDB_№_2 и сохранить ее в MDB_№_3.
похоже можно только транзитным вариантом из MDB_№_2 в MDB_№_1 а потом из MDB_№_1 в MDB_№_3.
или я че-то не догоняю..
такая ситуёвина по ходу для меня актуальная - при выводе сложных больших отчетов. | |
| |
| |
| |
|
|
| | мне находясь в MDB_№_1 нужно взять таблу из MDB_№_2 и сохранить ее в MDB_№_3. |
В МДБ1 создаем связанные таблицы с МДБ2 и МДБ3
запросом перекидываем данные. предварительно удалив старые. | |
| |
| |
| |
|
|
| | а как быть с полем Счетчик которое ключевое - оно то должно соответствовать, его мы при копировании таблицы с данныи сохраняем, а в слчае удления данных и "запросом перекидываем данные" - счетчик нам новые данные выдаст | |
| |
| |
| |
|
|
| | если данные в локальных таблицах НЕ будут изменяться, то это поле можно сделать ключевым, но не счетчиком а long | |
| |
| |
| |
|
|
| | конечно никаких изменений - только для укорения вытягивания дерева из земли да и копировать надо 4-6 табл. | |
| |
| |
| |
|
|
| | Предположение: А можно ли запросом вытаскивать минимум для дерева и этим запросом создавать таблицу на компе, после чего все остальное. | |
| |
| |
| |
|
|
| | проблема в тормозах при обращении к таблам, дерево - постоянно к ним обращается с новым условием where для каждого ветки. вот и мучаюсь. | |
| |
| |
| |
|
|
| | Жаль, что я забил на деревья.
А то бы подсказал тебе - как создавая новую строку в таблице - сразу указывать идентификатор узла и ветки в дереве.
-------------------------------
Я ба делал вместо дерева - два списка рядом.
В первом выбираем, а во втором отображается несколько веток ветвления, во втором выбираем - оно прыг в первый, а во втором опять несколько веток ветвления. И так до конца.. А потом в обратную сторону.
Для особо нетерпеливых самые "корни" - третий списочек.
================================================
Хотя канешно дерево удобнее - возможно.
Но тормозов бы тошно не было.  | |
| |
| |
| |
|
|
| | постоянно нужно отслеживать ВСЕ изменения в каждой ветке - в таком случае.
я другое придума - тож изврат, но че робить | |
| |
| |
| |
|
|
| | но че робить? -- работу!!!  | |
| |
| |
| |
|
|
| | Я наверное так и не въехал в проблемму - потому мне не понятно Ваше выражание - типа
постоянно нужно отслеживать ВСЕ изменения в каждой ветке - в таком случае.
|
Что отслеживать.... если всё заносится в таблицыс указанием ID родителя...
туплю , я... | |
| |
| |
| |
|
|
| |
Для особо нетерпеливых самые "корни" - третий списочек.
|
хотя бы про это | |
| |
| |
| |
|
|
| | Это имелося ввиду - само изделие -(полная сборка) | |
| |
| |
|
|
|
|
|
|
| |
|
|
| | Рад за народ 
=============================
для отчётов перегонять в зад! | |
| |
| |
