|
|
|
Переход от MDB к ADP
|
|||
|---|---|---|---|
|
#18+
База довольно приличная. ИМХО, здесь нужно исходить из времени. Если его много и в спину не дышат, то прав incold - писать с нуля, учитывая что, нужно время на освоение T-SQL. Если нет - тогда конвертировать mdb в adp. Времени уйдет меньше, но нужно будет мирится с тем, что логика останется на клиенте и полностью преимущества сервера не будут использованы. Нужно сразу переписать код с DAO на ADO (можно это сделать еще в mdb) Просмотреть запросы на предмет использования пользовательских функций и функций Access - они работать не будут. Нужно искать либо другие пути или создавать аналоги в виде функций на сервере. Полетят и все запросы с использованием параметров в виде =Form!мояФорма!поле и т.д. Т.е. от запросов мало что останется неизменным. А потом долгая возня с источниками форм, отчетов и контролов. Чистый выигрыш на этом варианте - не нужно переделывать дизайн и минимальное знание T-SQL. Но это тоже немало. Еще более прост вариант с OBDC - менять меньше, но и преимуществ еще меньше. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.11.2004, 01:16:23 |
|
||
|
Переход от MDB к ADP
|
|||
|---|---|---|---|
|
#18+
формы переделывать всё равно придется. меньше , но тут подправить, там немного... в основном переделывание запросов в хп. переходить не сложно , просто много времени... а переписыват заново.... продумывать дизайн, логику работы.... я бы не сталлл.... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.11.2004, 08:35:54 |
|
||
|
Переход от MDB к ADP
|
|||
|---|---|---|---|
|
#18+
Программист-Любитель Есть пошаговый отладчик с просмотром переменных для процедур. Это где это так? Alexander G Нужно сразу переписать код с DAO на ADO (можно это сделать еще в mdb) Думаю если переходить на ADP то даже если в mdb переписать все на ADO, потом все равно придется повторно код переписывать с учетом что sql конструкции будут обрабатываться на сервере, разве не так? ODBC не подходит это понятно, судя по форуму далеко не лучший вариант, тормоза и глюки обоспечены. вадя Заново логику продумывать не надо, если с нуляписать можно старый проект взять как техописание того что надо делать, т.е. логика вся уже придумана. Вчера всю голову сломал пока пытался найти лучшее решение, варианты были такие: 1) Оставить все как есть и не париться :) При достижении базой 2-х гигов вынести некоторые таблицы в отдельные mdb 2) Перекинуть таблицы на сервер, прилинковать к базе и готовиться к тормозам 3) Писать на VB.NET все формы с нуля. Лучший фариант это конечно брать по одной форме и перекидывать на ADP и смотреть какие таблицы она тянет, т.е. по тихоньку отлаживать новый проект перенося по одной форме. Причем надо как-то уже на этом этапе обеспечить возможность работы с перенесенными таблицами и новыми формами, потому что если перенести все таблицы на сервер оставив работать юзеров в старой базе, перелопатить новый проект, потом залить свежие данные в серверные таблицы и сразу дать юзерам работать с проектом, вылезет множество недосмотренных багов, причем сразу в нескольких местах и поправить это все в реальном времени наиболее оперативно не получится. Лучше как-то по одной форме переносить и давать сразу юзерам с этим работать чтобы в нормальном темпе можно было убрать баги. Голова кругом короче, не знаю как подступиться... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.11.2004, 09:45:51 |
|
||
|
Переход от MDB к ADP
|
|||
|---|---|---|---|
|
#18+
Я немного смешал в одну кучу Enterprise Manager и Query Analyzer. Написанное про стиль работы относилось к QA. Там же по правой кнопочке мыши на процедуре чудесная опция Debug... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.11.2004, 09:51:44 |
|
||
|
Переход от MDB к ADP
|
|||
|---|---|---|---|
|
#18+
В общем-то в клиентской части остается ТОЛЬКО визуализация данных. Загоняние агрументов в вызов хранимых процедур и всякие where и order by. Я предпочитаю формировать полную sql конструкцию для источника данных форм сам в коде VBA. Не пользуюсь LinkMaster/DetailFields подчиненных форм, не пользуюсь свойствами Filter и OrderBy форм. Формы, открываемые как обычные (acForm а не acDatasheet) у меня имеют в качестве источника записей единственную, на которую наложено что-то вроде PrimaryKey=конкретное значение. Это сделано по определенным соображениям. Условия отбора и сортировки контролируются моей логикой разработчика и не могут быть испорчены или заданы неправильно пользователем. Как правило для штатной работы нужна небольшая, но определенная выборка данных. Открытие форм, опирающихся на единственную запись не тащит с сервера большой объем данных. Когда они (данные) представляют собой сложные суммирующие запросы по большой базе, форма может просто не успеть открыться за отведенное ей время (лимит ожидания ответа от поставщика данных). Для перехода между записями надо вернуться в табличную форму и ходить по ней или нажать самодельные кнопочки "Поиск". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.11.2004, 10:03:52 |
|
||
|
Переход от MDB к ADP
|
|||
|---|---|---|---|
|
#18+
авторЛучший фариант это конечно брать по одной форме и перекидывать на ADP и смотреть какие таблицы она тянет, т.е. по тихоньку отлаживать новый проект перенося по одной форме правильный вариант. дополнение необходимо с использованием DTS сделать переност данных из мдб в sql причем это нада сделать сначала. скорее всего что просто перенести данные из мдб не получится.(шаг на который стоит обратить внимание) пренести данные и по одной форме переносить клиента. при таком варианте можно коверкать при отладке данные в sql , и в любой момент получить новые, правильные данные . и к моменту перехода на новую версию просто запустив DTS получить базу с последними данными уже в SQL. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.11.2004, 10:06:22 |
|
||
|
Переход от MDB к ADP
|
|||
|---|---|---|---|
|
#18+
А получится ли так в конце залить все рабочие данные чтобы не возникло вопросов с ключами, нулевыми полями и прочим? Почему кстати лучше делать это через DTS, а не через визарды Access 2002? Пока разбираюсь с вопросом переноса базы, читал в поиске что DTS не очень корректро переносит данные. В любом случае без скурпулезной проверки всех параметров таблицы от значений по умолчанию, до соответствию типов полей исходням таблицам не обойтись. Теперь по переработке форм. Придется проверять каждый элемент на форме на наличие кода. Я уже имел опыт переноски приложения написанного на VB на ADP платформу. Получилось так что некоторый код был упущен, слишком уж утомительно каждый элемент проверять, все не упомнишь. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.11.2004, 11:05:57 |
|
||
|
Переход от MDB к ADP
|
|||
|---|---|---|---|
|
#18+
Программист-Любитель Написанное про стиль работы относилось к QA. Там же по правой кнопочке мыши на процедуре чудесная опция Debug... Где это чудо? Не нашел чего-то. Т.е. в QA я например пишу exec sp_GetStorage и где я должен кликнуть чтобы найти дебаг? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.11.2004, 11:16:15 |
|
||
|
Переход от MDB к ADP
|
|||
|---|---|---|---|
|
#18+
авторА получится ли так в конце залить все рабочие данные чтобы не возникло вопросов с ключами, нулевыми полями и прочим? не получится, т.к. желательно для некоторых таб добавлять поле даташтамп. опять же корректно использовать преобразование форматов. дтс позволяет крректно переносит данные с учетом ключей т.е. правильно сохраняя связи. и для отладки необходимы данные которые можно портить. а формы я переношу так: создаю адр (таблицы сданными должны у же быть готовы). формы - импорт - мдб - выбираю одну головную фому, ежели помню подчиненные - их тоже. источник данных переделываю на хп запускаю головную. она на чём-то вылетает. смотрю где - переделываю и т.д. кажется долго, зато по шагам и надежно. пользоваться визардами не понравилось. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.11.2004, 11:19:56 |
|
||
|
Переход от MDB к ADP
|
|||
|---|---|---|---|
|
#18+
Alexander G Полетят и все запросы с использованием параметров в виде =Form!мояФорма!поле и т.д. Т.е. от запросов мало что останется неизменным. Извините, можно конкретный вопрос: как переделать подобный запрос? Напрашивается (предлагает "преобразователь" Access) : ALTER FUNCTION dbo.Запрос(@Forms___МояФорма___Поле int) RETURNS TABLE AS RETURN (SELECT DISTINCT тТаблица . КодТаблицы, ... FROM тТаблица ... WHERE (((тТаблица.КодТаблицы)=@Forms___МояФорма___Поле))) - но не работает. Что же нужно вместо @Forms___МояФорма___Поле?? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.11.2004, 11:37:22 |
|
||
|
Переход от MDB к ADP
|
|||
|---|---|---|---|
|
#18+
Идем в QA. Встаем на нужную БД. В левой части - броузер объектов. Открываем хранимые процедуры, выбираем нужную и кликаем правой кнопкой мышки. В меню есть заветный пункт "Debug". В седьмом, по-моему, такого еще не был. Начиная с 2000 сервера. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.11.2004, 11:47:27 |
|
||
|
Переход от MDB к ADP
|
|||
|---|---|---|---|
|
#18+
авторПрограммист-Любитель Что ж ты раньше-то молчал все эти годы??? :) Блин, кто бы подумал что там еще и браузер объектов есть. Попробую сегодня этот чудодейственный дебаг, спасибо! :) вадя Я тебя немного непонял, сначала мы заливаем через DTS все таблицы как получится, ковыряем их проверяем, перетаскиваем из базы формочки в проект и уговариваем их работать с этими таблицами. Все, написали проект. Все как бы работает. Теперь как нам перелить свежие данные в таблицы на сервере? Ты уверен что они без проблем зальются туда? И потом если ты где-то что-то проглядел при перестройке форм (неизбежно) и юзеры начнут работу с базой, причем каждый со своей областью, то эти глюки повылазят в большом количестве и ты не успеешь все их убрать чтобы не поднялся ор или не потерялось много данных. Я же говорю о том как бы сделать перенос по одной формочке и причем после ее отладки сразу дать народу работать с ней, паралельно продолжая работать со старой базой, но в которой это формы уже нет. Т.е. как умудриться постепенно смещать проект давая юзерам работать с уже переделанными частями и получая возможность отлавливать глюки по очереди для каждой формы, а не утонуть потом сразу получив их ото всюду. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.11.2004, 12:08:03 |
|
||
|
Переход от MDB к ADP
|
|||
|---|---|---|---|
|
#18+
Насчет дебагера 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' Что-то я не помню такой фишки на диске, щас гляну. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.11.2004, 13:11:10 |
|
||
|
Переход от MDB к ADP
|
|||
|---|---|---|---|
|
#18+
авторТеперь как нам перелить свежие данные в таблицы на сервере? дак используя dts , в котором нада составить скрипт (графически + текстовый, довольнотаки удобно, нада приноровиться ) которым сначала будеш сливать данные для пробы, отладки. как только клиент будет готов - окончательно сливаешь данные и все. ну а сам процесс перехода - это пестня особая нада попытаться некоторых (самых терпеливых, заинтересованных) юзеров вести параллельно и мдб и адр . будешь отлавливать ошибки и проверять логику и все прочее по контрольным цифрам. неправильная работа адр (искажение данных) не страшна , после исправления очередной ошибки спокойно сливаешь при помощи dts правильные данные и вперед. перед сливанием необходимо очистить sql базу либо удалением всех записей ,либо созданиеем по новой всех даблиц из dts 9кому как нравтся) постепенно смещать не получится... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.11.2004, 14:26:51 |
|
||
|
Переход от MDB к ADP
|
|||
|---|---|---|---|
|
#18+
Как DTS правильно воспользоваться не соображу никак? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.11.2004, 15:29:33 |
|
||
|
Переход от MDB к ADP
|
|||
|---|---|---|---|
|
#18+
Описания полей базы Access не хотят переноситься в SQL, где копать? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.11.2004, 15:34:24 |
|
||
|
Переход от MDB к ADP
|
|||
|---|---|---|---|
|
#18+
Нельзя перенести из Access в SQL: - маски ввода - условия на значения (некоторые) - значения по умолчанию (некоторые) - allow zero length - индексы и межтабличные связи :( ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.11.2004, 16:37:37 |
|
||
|
Переход от MDB к ADP
|
|||
|---|---|---|---|
|
#18+
Кстати, хотя может и не по теме. Ас"97 Программа на N пользователей с разделением уровня доступа по данным и правам). mdb-клиента (50Mb) + mdb-данные(200Mb), 2-процессорный сервер по 3,2Mg+1Gb Оп+скази зеркало. WIN2003server. Ставлю mdb-данные на сервер + N копий mdb-клиента (N- кол-во пользователей). На клиентских ПК - терминал. Все летает, порхает и проблем пока (тьфу,тьфу) нет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.11.2004, 17:27:16 |
|
||
|
Переход от MDB к ADP
|
|||
|---|---|---|---|
|
#18+
авторmdb-клиента (50Mb) ты уверен, что у тебя клиент в хорошем состоянии? автор- индексы и межтабличные связи связи переносятся, индексы желательно переосмыслить... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.11.2004, 19:14:56 |
|
||
|
Переход от MDB к ADP
|
|||
|---|---|---|---|
|
#18+
авторКак DTS правильно воспользоваться не соображу никак? в EM есть пункт Data Trans.... Servis вот там и копаешь..... к сожалению так объяснить не смогу...., но учитывая, что сам дошел, думаю, что и ты сможешь, главное не пугаться ... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.11.2004, 19:37:01 |
|
||
|
Переход от MDB к ADP
|
|||
|---|---|---|---|
|
#18+
Кстати, еще пара соображений. DTSом я пользовался, пока Linked Server не наладил. После этого все процедуры перемещения (откачки и закачки) данных можно писать на нормальном sql. Можно как сделать связанные c сервером таблицы в MDB базе так и наборот подлинковать MDB таблицы к sql серверу. Правда, оговорюсь, что внешний источник у меня специфический - фирменная база данных на майнфрейме AS/400. Причем только на чтение. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.11.2004, 23:09:36 |
|
||
|
Переход от MDB к ADP
|
|||
|---|---|---|---|
|
#18+
вадя авторmdb-клиента (50Mb) ты уверен, что у тебя клиент в хорошем состоянии? Уверен! Это он после сжатия такой худенький. Ну так форм, отчетов, запросов - немерено. (...ну и мусор иногда попадается...наверное). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.11.2004, 11:17:44 |
|
||
|
Переход от MDB к ADP
|
|||
|---|---|---|---|
|
#18+
авторУверен! Это он после сжатия такой худенький. А после /decompile ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.11.2004, 12:24:05 |
|
||
|
Переход от MDB к ADP
|
|||
|---|---|---|---|
|
#18+
PantaloneА получится ли так в конце залить все рабочие данные чтобы не возникло вопросов с ключами, нулевыми полями и прочим? Почему кстати лучше делать это через DTS, а не через визарды Access 2002? Пока разбираюсь с вопросом переноса базы, читал в поиске что DTS не очень корректро переносит данные. В любом случае без скурпулезной проверки всех параметров таблицы от значений по умолчанию, до соответствию типов полей исходням таблицам не обойтись. Теперь по переработке форм. Придется проверять каждый элемент на форме на наличие кода. Я уже имел опыт переноски приложения написанного на VB на ADP платформу. Получилось так что некоторый код был упущен, слишком уж утомительно каждый элемент проверять, все не упомнишь. Не знаю. зачем Вам для переноса mdb на adp DTS нужны.... они, пакеты, немного не для этого заточены. Обычный Upsizing Wizard вполне справляется... до некоторых пределов, естественно, не все конструкции jet перенесутся. Придется весьма и весьма поработать, проверяя не только таблицы, но и запросы. И лучше все запросы переписать. Ну, я бы так сделал. SQL все же по синтаксису и возможностям отличается. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.11.2004, 13:29:04 |
|
||
|
Переход от MDB к ADP
|
|||
|---|---|---|---|
|
#18+
Shurgenz Не знаю. зачем Вам для переноса mdb на adp DTS нужны.... они, пакеты, немного не для этого заточены. Обычный Upsizing Wizard вполне справляется... А как потом после переписания базы данные залить из старой mdb? Думаю что надо лить в уже готовые откорректированные пустые макеты таблиц, но чем лить и как убедиться что все залито корректно, без пропусков записей или значений полей? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.11.2004, 17:11:36 |
|
||
|
|

start [/forum/topic.php?fid=45&msg=32800984&tid=1670042]: |
0ms |
get settings: |
8ms |
get forum list: |
13ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
47ms |
get topic data: |
8ms |
get forum data: |
2ms |
get page messages: |
61ms |
get tp. blocked users: |
1ms |
| others: | 205ms |
| total: | 351ms |

| 0 / 0 |
