| |
|
|
| | В принципе в ближайшее время я не собираюсь переходить с ADP на MDB. Но вдруг это мне понадобится? Но в интернете я не нашла об этом ничего. Об обычном переходе с MDB на ADP говорится везде. Но обратный переход - это либо глупо либо невозможно либо я снова проявляю ненужное любопытство.
Из ADP перенести все модули, отчеты и формы несложно. По крайней мере мне ни о каких ошибках не сообщалось. Поэтому чисто поверхностно я предполагаю, что здесь проблем быть не должно.
Соответственно, таблицы и запросы нужно переносить из MDF, правильно? А для этого есть какие-то инструменты? | |
| |
| |
| |
|
|
| | Скопировать таблицы и все. | |
| |
| |
| |
|
|
| | А тригеры, а пользовательские функции Вы как собираетесь переносить? | |
| |
| |
| |
|
|
| | Пока никак не собираюсь. Поэтому и интересуюсь, насколько это глупая мысль. Но судя по тому, что об этом ничего не написано, это невозможно или возможно с большими потерями. | |
| |
| |
| |
|
|
| | суть в том, что в ADP немного другая концепция разработки программ, чем в MDB. Кроме того в MDB нет таких понятий как пользовательские функции и триггеры. Синтаксис запросов в MDB и ADP различные. Перенос возможен, но не совсем понятно зачем он может понадобиться? Обычно количество пользователей и размер БД увеличиваются, а не уменьшаются. | |
| |
| |
| |
|
|
| | Это возможно. И возможно, что это будет с большими потерями. Например, такой вещи, как хранимки в аксе нет. А с помощью хранимок в SQL server можно решить кучу проблем, которые в аксе решить сложно. Если у вас в ADP используются хранимки, то придется многое переписывать заново. У себя, например, я использую хранимки даже там, где можно использовать вьюхи.
Про триггеры и пользовательские функции уже говорилось выше | |
| |
| |
| |
|
|
| | если честно, то я пока тоже не знаю, зачем мне это может понадобится. Спросила из любопытства.
Как всегда, благодаря Вам поняла, что это вряд ли стоит делать. А значит мне это и не понадобится. Спасибо, что не сказали просто, что это глупо и невозможно, а объяснили, почему. Зато мне теперь это ясно. | |
| |
| |
| |
|
|
| | Есть определенные проблемы при обратном переходе, с которыми я столкнулся. ADP работает в табл. SQL сервера напрямую, а MDB посредством ODBC или надо подключать ADOX, возникла хитрая ситуация, с табл. из ADP все прекрасно, а из MDB через ODBC не дает править запись - выбрасывает конфликт (понятно, что нико другой запись и не правил). Что только не пробовал - ничего, так и осталось темное пятно. Причем только с одной табл. Конечно, обратный переход несколько противоестественнен, но меня заставила нужда из-за файла рабочих групп, в ADP другая идентификация пользователя, т.е. я не знаю как сделать на прямую - использовать или подключить MDW. Наверное нужно в табл. пользователей заводить поле, в которое положить виндовский идентификатор пользователя и пользоваться не CurrentUser, а чем-то другим и брать строку соответсвия по полям mdw и winows
Если кто-то обладает опытом ведения нескольких баз ADP и MDB одновременно, был бы благодарен за описание граблей, а то у меня на голове уже мало места осталось ... :) | |
| |
| |
| |
|
|
| | Файл рабочих групп стал причиной перехода обратно на MDB? 
А не проще сделать разграничение прав на уровне пользователей с помощью кода? Плюс будут полномочия, передаваемые самим SQL server.
Я даже примерчики могу приложить, если нужно, как сделать разграничение прав в коде. Мне на этом сайте с этим помогли, я быстро все поняла и сделала.
А что касается файла рабочих групп, то как я поняла, им пользуются далеко не все. Когда я обсуждала тему о полномочиях, то поняла, что многие делают в коде. Чем лучше файл рабочих групп - я так и не поняла. А точнее, вряд ли он лучше. Может просто проще с ним. Но в коде делать, мне кажется, удобнее.
Хотя я сама разницу не смогу объяснить нормально, это отлично сделают корифеи этого форума. Но лично мне удобнее и нагляднее делать в коде. | |
| |
| |
| |
|
|
| | интересно взглянуть на код разграничения прав пользователей ... | |
| |
| |
