Hallo,
wenn ich eine Anwendung habe die
per ADO auf Accessdateien zugreift,
nun aber auf MSSQL umsteigen will,
was ist da zu ändern?
Den MSSQL-Server Express gibt es ja IMHO
frei erhältlich, so dass man ihn mit der
Anwendung verteilen kann?!
Welche Komponenten sind dafür erforderlich
und sind diese ebenfalls frei?

Grüße nachträglich an alle Väter

Du musst hier grundsätzlich relativ wenig ändern. Per Ado kann man problemlos auf MSSQL zugreifen

Zitat von Privateer3000:

was ist da zu ändern?

Zu 90% wird die Änderung deinen SQL-Quellcode betreffen:
- Umstellen von Serverside-Curser auf CLient-Side
- Kontrolle und anpassung all deiner Access-Spezifischen Query-Statements
- Ersetzen aller TADOTable (und am besten TADOQuery) durch TADODataset

Am besten ist es alle DB-Zugriffe in eine Unit zu packen, darüber das Bridge-Pattern zu implementieren und dann mehrere DB's zu unterstützen.

Danke Leute,
ich glaube dass ich keine Access-typischen SQLstrings verwendet habe.
Auch aggregate wie sum,max u.ä. sind ja nichts besonderes.
Die Verbindung wird ja per ADOConnection hergestellt, wird diese
auch verwendet und nur der Connectionstring angepasst?

Zitat von Bernhard Geyer:

Zu 90% wird die Änderung deinen SQL-Quellcode betreffen:
- Umstellen von Serverside-Curser auf CLient-Side
- Kontrolle und anpassung all deiner Access-Spezifischen Query-Statements
- Ersetzen aller TADOTable (und am besten TADOQuery) durch TADODataset

Am besten ist es alle DB-Zugriffe in eine Unit zu packen, darüber das Bridge-Pattern zu implementieren und dann mehrere DB's zu unterstützen.

ADOTable hab ich garnicht verwendet sondern die Querys und Datasets.

Zitat:

Ersetzen aller TADOTable (und am besten TADOQuery) durch TADODataset

Query durch Dataset ersetzen? Wird dann der SQLstring an das Dataset gesendet?

Zitat:

Umstellen von Serverside-Curser auf CLient-Side

Das habe ich garnicht verstanden. Was ist damit genau gemeint?

Umsteigen möchte ich deswegen um die Multiconnection zu gewährleisten,
damit mehrere gleichzeitig auf die Tabellen zugreifen können!

Das geht mit access doch auch

ich habe aber immer wieder gelesen,
dass es da Probleme damit gibt.
Wenn mehr als einer auf eine Tabelle
der DB zugreift.

Also wir haben es so gelöst, dass wir für jeden Benutzer eine MDB erstellt haben, die dann aber nur auf die Tabellen der "scharfen" Daten verknüpft ist. So öffnet jeder Benutzer seine eigenen Tabellen, es greifen aber alle auf die gleichen Daten zu.

Zitat von Privateer3000:

Query durch Dataset ersetzen? Wird dann der SQLstring an das Dataset gesendet?

Durch das CommandText-Property. TADOTable/TADOQuery sind mit ein paar Bugs behaftet die das TADODataset nicht hat und sind primär für einfachere BDE-Umstellungen gedacht.

Zitat von Privateer3000:

Zitat:

Umstellen von Serverside-Curser auf CLient-Side

Das habe ich garnicht verstanden. Was ist damit genau gemeint?

Bei Access sollte man Serverside Curser verwenden da ja eine Desktop-Datenbank vorliegt und ein Clientside-Curser nur unnötige Speicher-Kopieraktionen bedeutet. Bei einem SQL Server sollte man primär Client-Side Curser benutzen um die Last auf dem DB-Server nicht unnötig lange aufrecht zu erhalten (Temporärtabellen, etc)

Interessanter Ansatz,
mit Verknüpfungen hatte ich noch nichts am Hut.
Das gilt für Lese- und Schreibvorgänge?! So das
die Daten auch in die "scharfen" Tabellen geschrieben werden?
Wie verhält es sich mit den Bedingungen, nagelt man sich
damit fest, dass die Verknüpfung existieren muss oder wird
erkannt wenn diese nicht exisitert. Quasi als Standalone
verwendet wird.

Zitat von Bernhard Geyer:

Zitat von Privateer3000:

Query durch Dataset ersetzen? Wird dann der SQLstring an das Dataset gesendet?

Durch das CommandText-Property. TADOTable/TADOQuery sind mit ein paar Bugs behaftet die das TADODataset nicht hat und sind primär für einfachere BDE-Umstellungen gedacht.

Zitat von Privateer3000:

Zitat:

Umstellen von Serverside-Curser auf CLient-Side

Das habe ich garnicht verstanden. Was ist damit genau gemeint?

Bei Access sollte man Serverside Curser verwenden da ja eine Desktop-Datenbank vorliegt und ein Clientside-Curser nur unnötige Speicher-Kopieraktionen bedeutet. Bei einem SQL Server sollte man primär Client-Side Curser benutzen um die Last auf dem DB-Server nicht unnötig lange aufrecht zu erhalten (Temporärtabellen, etc)

Du meinst damit die Eigenschaft CursorLocation?!