Access 2002 към MS SQL 2000
7 отговора
322 прегледа
Re: Access 2002 към MS SQL 2000
Ima malko problemi...
be6e otdawna no towa koeto si spomnqm e 4e auto-increment (wyw sql server Identity) columns trqbwa da si gi syzdade6 ry4no (ne se importwat ot sql server), ako ima6 memo poleta, te stawat nvarchar s dylvina rawna na teku6tiq nai-dylyd text w kolonata... Mislq 4e ima6e i o6te ne6ta koito trqbwa da se donaglasqt, ogledai wnimatelno tablicite za6toto dosta ne6ta gi nqma a na pryw pogled wsi4ko izglevda ok :)
be6e otdawna no towa koeto si spomnqm e 4e auto-increment (wyw sql server Identity) columns trqbwa da si gi syzdade6 ry4no (ne se importwat ot sql server), ako ima6 memo poleta, te stawat nvarchar s dylvina rawna na teku6tiq nai-dylyd text w kolonata... Mislq 4e ima6e i o6te ne6ta koito trqbwa da se donaglasqt, ogledai wnimatelno tablicite za6toto dosta ne6ta gi nqma a na pryw pogled wsi4ko izglevda ok :)
Re: Access 2002 към MS SQL 2000
Благодаря.
Има още много други неща които ме притесняват относно тази миграция. Ако някой има още какво да каже ще бъда много благодарен.
Ето някои от въпросите които ме интересуват.
1. Ако разделя проекта на фронт енд и база данни, не е ли по добре да използвам DTS на SQL Server 2000 за базата данни за да прехвърля таблиците от Jet към SQL Server?
2. Що се касае до интерфейсната част не е ли по добре да я трансформормирам в Access Data Project чрез Upsizing Wizard на Майкрософт?
3. Направил съм предварителна подготовка като голяма част от DAO кода съм го пренаписал на ADO както се изисква за достъп да SQL таблици. Имам обаче локални таблици в интерфейсната част на проекта, ще трябва ли и обръщенията към тях да са чрез използване на ADO?
Има някои таблици достъпа до които трябва да е много бърз, защото това е решаващо за бързодействието на програмата. Тези таблици остават в интерфейсната част.
Установих че достъпа до данните чрез DAO и най-вече SEEK функцията е много бърза и съм оптимизирал кода за постигане на бърз достъп.
Въпросът ми е ще трябва ли достъпа до таблици от фронт енд проекта също да е чрез ADO? Необходимо ли е целия достъп до всички таблици да се прехвърли чрез ADO интерфейса за достъп до данните?
Има още много други неща които ме притесняват относно тази миграция. Ако някой има още какво да каже ще бъда много благодарен.
Ето някои от въпросите които ме интересуват.
1. Ако разделя проекта на фронт енд и база данни, не е ли по добре да използвам DTS на SQL Server 2000 за базата данни за да прехвърля таблиците от Jet към SQL Server?
2. Що се касае до интерфейсната част не е ли по добре да я трансформормирам в Access Data Project чрез Upsizing Wizard на Майкрософт?
3. Направил съм предварителна подготовка като голяма част от DAO кода съм го пренаписал на ADO както се изисква за достъп да SQL таблици. Имам обаче локални таблици в интерфейсната част на проекта, ще трябва ли и обръщенията към тях да са чрез използване на ADO?
Има някои таблици достъпа до които трябва да е много бърз, защото това е решаващо за бързодействието на програмата. Тези таблици остават в интерфейсната част.
Установих че достъпа до данните чрез DAO и най-вече SEEK функцията е много бърза и съм оптимизирал кода за постигане на бърз достъп.
Въпросът ми е ще трябва ли достъпа до таблици от фронт енд проекта също да е чрез ADO? Необходимо ли е целия достъп до всички таблици да се прехвърли чрез ADO интерфейса за достъп до данните?
Re: Access 2002 към MS SQL 2000
1...
DTS se izpolzwa za periodi4no prehwyrlqne na danni ot edna sreda w dryga sread (ne e zadylvitelno da e SQL server). Po princip move6 da izpolzwa6 DTS za da si prehwyrli6 dannite, no ne se podlygwai ot transformation 4astta na DTW sykra6tenieto... Kakwoto move6 da naprawi6 s DTS move6 da si go naprawi6 i s ad hoc queries sled kato prosto importne6 dannite ot access-a. S DTS samo 6te uslovni6 rabotata i 6te postigne6 sy6tiq efekt... Ako nqma da prehwyrlq6 po-kysno o6te danni (kato towa prehwyrlqne da sledwa sy6tite prawila na pyrwoto), to ne si zasluvawa da se izpozwa DTS. DTS ne e tool za importwane na danni, a po-skoro za periodi4no import-wane i update-wane na danni...
Iny4e sys sigurnost 6te si razdeli6 proektna na frontend i backend... SQL ne predlaga na4ini za syzdawane na kakywto i da e frontend :)
2...
tuk nqmam po4ti nikakwa kompetentnost... nikoga ne sym izpolzwa upsizing wizard...
3...
Move6 da prodylvi6 da izpolzwa6 DAO (koeto zawisi ot frontend-a ti w slu4aq), wse o6te se poddyrva, no ideqta e 4e Microsoft go zamenqt s ADO. Do nqkolko godini we4e nikoi nqma da e 4uwal za DAO i 6te byde prosto otviwelica, koqto se poddyrva mnogo trudno. Oswen towa Microsoft twyrdi 4e ADO e pyti po-byrzo ako se izpolzwa po prawilniq na4in...
DTS se izpolzwa za periodi4no prehwyrlqne na danni ot edna sreda w dryga sread (ne e zadylvitelno da e SQL server). Po princip move6 da izpolzwa6 DTS za da si prehwyrli6 dannite, no ne se podlygwai ot transformation 4astta na DTW sykra6tenieto... Kakwoto move6 da naprawi6 s DTS move6 da si go naprawi6 i s ad hoc queries sled kato prosto importne6 dannite ot access-a. S DTS samo 6te uslovni6 rabotata i 6te postigne6 sy6tiq efekt... Ako nqma da prehwyrlq6 po-kysno o6te danni (kato towa prehwyrlqne da sledwa sy6tite prawila na pyrwoto), to ne si zasluvawa da se izpozwa DTS. DTS ne e tool za importwane na danni, a po-skoro za periodi4no import-wane i update-wane na danni...
Iny4e sys sigurnost 6te si razdeli6 proektna na frontend i backend... SQL ne predlaga na4ini za syzdawane na kakywto i da e frontend :)
2...
tuk nqmam po4ti nikakwa kompetentnost... nikoga ne sym izpolzwa upsizing wizard...
3...
Move6 da prodylvi6 da izpolzwa6 DAO (koeto zawisi ot frontend-a ti w slu4aq), wse o6te se poddyrva, no ideqta e 4e Microsoft go zamenqt s ADO. Do nqkolko godini we4e nikoi nqma da e 4uwal za DAO i 6te byde prosto otviwelica, koqto se poddyrva mnogo trudno. Oswen towa Microsoft twyrdi 4e ADO e pyti po-byrzo ako se izpolzwa po prawilniq na4in...
Re: Access 2002 към MS SQL 2000
Благодаря много за мненията по отделните въпроси.
Бих искал да видя някои реализации на SQL бази данни и по точно на сървърната част. Интересува ме използването на тригери и ефективното прехвърляне на Visual Basic кода към сървъра.
Както знаете при файл сървърната организация Access поема цялата обработка и товари мрежата. При новата организация изглежда ще е нужно първо да се създаде самата схема на базата данни в MS SQL 2000 вариант, като се изхожда от схемата на данните в Access.
Очивидно простото изкопиране на структурите тук няма да е много от полза, а е по-добре да се използват многобройните възможности на SQL Server.
От къде бих могъл да намеря такива реализирани примерни решения?
Предварително благодаря на всеки който помогне.
Бих искал да видя някои реализации на SQL бази данни и по точно на сървърната част. Интересува ме използването на тригери и ефективното прехвърляне на Visual Basic кода към сървъра.
Както знаете при файл сървърната организация Access поема цялата обработка и товари мрежата. При новата организация изглежда ще е нужно първо да се създаде самата схема на базата данни в MS SQL 2000 вариант, като се изхожда от схемата на данните в Access.
Очивидно простото изкопиране на структурите тук няма да е много от полза, а е по-добре да се използват многобройните възможности на SQL Server.
От къде бих могъл да намеря такива реализирани примерни решения?
Предварително благодаря на всеки който помогне.
Re: DAO достъп до MS SQL 2000 невъзможен
Няма достъп до SQL Server 2000, чрез DAO, от опита ми с Access 97 и сега 2002 разбрах, че DAO e по-бърз за собствените таблици на приложението. Що се касае до свързаните таблици, там вече не съм категоричен.
Това което искам е с Access Data Project да работа с MS SQL Server 2000. Понеже работя и с двете библиотеки DAO и Active X Data Objects пробвах с DAO и виждам, че се получава грешка. По-горе в дискусията се казваше че можело и с DAO - виждам че не може.
Това което искам е с Access Data Project да работа с MS SQL Server 2000. Понеже работя и с двете библиотеки DAO и Active X Data Objects пробвах с DAO и виждам, че се получава грешка. По-горе в дискусията се казваше че можело и с DAO - виждам че не може.