Хлопцы, начинаю заниматься сабжем, рыдать хочется, ну куда предыдущий программист смотрел? Какого было такую навороченную базу на Access делать? И началтьству в тык дать бы, платили бы нормально, он не ушел бы и может сам перевел бы на сиквел все свое хозяйство:
140 таблиц
300 запросов
120 форм
240 отчетов
35 модулей
Что меня ждет подскажите и с чего лучше начать.
Таблицы качать мастером SQL сервера или експортнуть визардом Access XP?
Насколько корректно типы полей будут интерпретированы?
Связи между таблицами удасться передать?
Запросы лучше каждый с нуля пересоздать?

А может лучше сразу повеситься? :)
База порядка 700 мег...

автор- получить полоноценное приложение клиент-сервер с возможностью дальнейшего расширения функциональности

incold
Согласен, в этом есть разумное зерно, но по большому счету это абсурд, такую гомадину заново переписывать...
У меня вот тоже щас мысль проскакивала: перекинуть таблицы кое-как ,а клиента на VB.NET состряпать... Но при ADP даже формы переделывать не придется, кое-где подправить и все.

Программист-Любитель Есть пошаговый отладчик с просмотром переменных для процедур.
Это где это так?

Alexander G Нужно сразу переписать код с DAO на ADO (можно это сделать еще в mdb)
Думаю если переходить на ADP то даже если в mdb переписать все на ADO, потом все равно придется повторно код переписывать с учетом что sql конструкции будут обрабатываться на сервере, разве не так?

ODBC не подходит это понятно, судя по форуму далеко не лучший вариант, тормоза и глюки обоспечены.

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


Вчера всю голову сломал пока пытался найти лучшее решение, варианты были такие:
1) Оставить все как есть и не париться :) При достижении базой 2-х гигов вынести некоторые таблицы в отдельные mdb
2) Перекинуть таблицы на сервер, прилинковать к базе и готовиться к тормозам
3) Писать на VB.NET все формы с нуля.

Лучший фариант это конечно брать по одной форме и перекидывать на ADP и смотреть какие таблицы она тянет, т.е. по тихоньку отлаживать новый проект перенося по одной форме. Причем надо как-то уже на этом этапе обеспечить возможность работы с перенесенными таблицами и новыми формами, потому что если перенести все таблицы на сервер оставив работать юзеров в старой базе, перелопатить новый проект, потом залить свежие данные в серверные таблицы и сразу дать юзерам работать с проектом, вылезет множество недосмотренных багов, причем сразу в нескольких местах и поправить это все в реальном времени наиболее оперативно не получится. Лучше как-то по одной форме переносить и давать сразу юзерам с этим работать чтобы в нормальном темпе можно было убрать баги.
Голова кругом короче, не знаю как подступиться...

А получится ли так в конце залить все рабочие данные чтобы не возникло вопросов с ключами, нулевыми полями и прочим?
Почему кстати лучше делать это через DTS, а не через визарды Access 2002?
Пока разбираюсь с вопросом переноса базы, читал в поиске что DTS не очень корректро переносит данные.
В любом случае без скурпулезной проверки всех параметров таблицы от значений по умолчанию, до соответствию типов полей исходням таблицам не обойтись.
Теперь по переработке форм. Придется проверять каждый элемент на форме на наличие кода. Я уже имел опыт переноски приложения написанного на VB на ADP платформу. Получилось так что некоторый код был упущен, слишком уж утомительно каждый элемент проверять, все не упомнишь.

Программист-Любитель Написанное про стиль работы относилось к QA. Там же по правой кнопочке мыши на процедуре чудесная опция Debug...
Где это чудо? Не нашел чего-то.
Т.е. в QA я например пишу exec sp_GetStorage и где я должен кликнуть чтобы найти дебаг?

авторПрограммист-Любитель
Что ж ты раньше-то молчал все эти годы??? :)
Блин, кто бы подумал что там еще и браузер объектов есть. Попробую сегодня этот чудодейственный дебаг, спасибо! :)

вадя
Я тебя немного непонял, сначала мы заливаем через DTS все таблицы как получится, ковыряем их проверяем, перетаскиваем из базы формочки в проект и уговариваем их работать с этими таблицами.
Все, написали проект. Все как бы работает.
Теперь как нам перелить свежие данные в таблицы на сервере? Ты уверен что они без проблем зальются туда? И потом если ты где-то что-то проглядел при перестройке форм (неизбежно) и юзеры начнут работу с базой, причем каждый со своей областью, то эти глюки повылазят в большом количестве и ты не успеешь все их убрать чтобы не поднялся ор или не потерялось много данных.
Я же говорю о том как бы сделать перенос по одной формочке и причем после ее отладки сразу дать народу работать с ней, паралельно продолжая работать со старой базой, но в которой это формы уже нет. Т.е. как умудриться постепенно смещать проект давая юзерам работать с уже переделанными частями и получая возможность отлавливать глюки по очереди для каждой формы, а не утонуть потом сразу получив их ото всюду.

Насчет дебагера QA ругается
авторThe debugger interface is not installed. Please re-run setup, select 'add components to your existing installation' and make sure you select 'Development tools' \ 'Debugger Interface'
Что-то я не помню такой фишки на диске, щас гляну.

Как DTS правильно воспользоваться не соображу никак?

Описания полей базы Access не хотят переноситься в SQL, где копать?

Нельзя перенести из Access в SQL:
- маски ввода
- условия на значения (некоторые)
- значения по умолчанию (некоторые)
- allow zero length
- индексы и межтабличные связи
:(

Shurgenz Не знаю. зачем Вам для переноса mdb на adp DTS нужны.... они, пакеты, немного не для этого заточены. Обычный Upsizing Wizard вполне справляется...
А как потом после переписания базы данные залить из старой mdb?
Думаю что надо лить в уже готовые откорректированные пустые макеты таблиц, но чем лить и как убедиться что все залито корректно, без пропусков записей или значений полей?

А как быть с индексами, счетчиками, связями и описанием полей?
DTS смогет это из ассесса вытащить?