Umstellung von ADS Local Server auf MS SQL 2005 Express

[Grolle]

Hallo,
aufgrund einiger Anfragen möchte ich meine Anwendung auf MS SQL 2005 umstellen.
Derzeit benutze ich den ADS Local Server. Für den Zugriff benutze ich AdsTable.
Was muss ich bei der Umstellung beachten, bzw. kann mir jemand sagen, wie ich am
Besten vorgehen sollte?
Viele Grüße ...

[f.siebler]

moin,

einfach mal testen wie es sich verhält, und schauen ob es überhaupt möglich ist ads table mit einem mssql server zu verbinden.... ansonsten "einfach" die komponenten austauschen...

[Bernhard Geyer]

Zitat von f.siebler:

moin,

einfach mal testen wie es sich verhält, und schauen ob es überhaupt möglich ist ads table mit einem mssql server zu verbinden.... ansonsten "einfach" die komponenten austauschen...

Und dann die 1000 unterschiede im SQL-Dialekt anpassen ... (TAds*-Kompos können nicht mit MS SQL-Server arbeiten).

Kapsle deinen DB-Zugriff in einer Unit und bau dir eine Abstraktionsschicht in deine Anwendung ein und Unterstütze beide Datenbanken.

[Grolle]

Zitat von Bernhard Geyer:

Kapsle deinen DB-Zugriff in einer Unit und bau dir eine Abstraktionsschicht in deine Anwendung ein und Unterstütze beide Datenbanken.

Das ist eine gute Idee. Ich denke, dass ist der richtige Ansatz für mich. Kennt jemand noch ein Tutorial o. ä.
für den Zugriff zum MS SQL Server, erstellen der Datenbank usw.? Habe noch nie mit MS SQL gearbeitet.
Viele Grüße ...

[hoika]

Hallo,

da bietet dir MS ne Menge auf der HP,
auch Weblogs.


Heiko

[Union]

Ohne Abstratktionsschicht geht es auch. Dafür könntest Du Deine Anwendung zuerst auf ADO umstellen, so dass sie noch mit ADS läuft und dann anpassen, bis es sowhol mit ADS als auch MSSQL funktioniert. Hier mal eine Aufstellung was man alles anpassen muss (kein Anspruch auf Vollständigkeit):

• - Parameter werden anders angesprochen
  - Doppelte Parameter müssen über den Index auch direkt gesetzt werden
  - Lange laufende Queries müssen durch Setzen von CommandTimeout erlaubt werden
  - RecordCount funktioniert nur mit clUseClient
  - Cursortype muss auf ctKeyset gesetzt werden
  - MSSQL: Parameter für CONVERT() sind umgedreht wie bei ADS
  - MSSQL: GROUP BY muss umgestellt werden, und es muss manuell ORDER BY angefügt werden
  - MSSQL: ORDER BY muss umgestellt werden (Namen )
  - MSSQL: Keine Unterstützung von Boolean. Bei Bit muss alles umgestellt werden auf 0/1
  - MSSQL: ID ist reserviertes Wort
  - MSSQL: iif() benötigt Analysis Services und Data Mining. Ersetzen durch CASE
  - MSSQL: Convert Date nicht empfehlenswert
  - MSSQL: String-Datumsformat anders als bei ADS, bei Literalen aufpassen

[Bernhard Geyer]

Zitat von Union:

Dafür könntest Du Deine Anwendung zuerst auf ADO umstellen, ...

Und damit einen der Hauptvorteile der bisherigen ADS-Lösung verlieren? Installationsfreie Verwendung der Datenbank!
ADO bitte nur bie MS SQL-Server und Access verwenden. Für alle anderen DBMS gibts bessere (direktere) Zugriffslösungen

Zitat von Union:

Hier mal eine Aufstellung was man alles anpassen muss (kein Anspruch auf Vollständigkeit):

Und mit dieser Liste lieferst du genau die Argumente eine Abstraktionsschicht einzuführe. Diese soll genau diese Unterschiede kapseln.

[Union]

Und wie sähe dann ein solches Bridging aus im konkreten Fall? Mann kann ja dann wohl kaum mehr direkt SQL-Statements absetzen - es sei denn, man schreibt sich einen Parser und erfindet einen eigenen SQL-Dialekt, der in eigenen Table- und Query-Komponenten verwendet wird. So was nachträglich umzustellen halte ich für ziemlich aussichtslos.

[Bernhard Geyer]

Zitat von Union:

Und wie sähe dann ein solches Bridging aus im konkreten Fall? Mann kann ja dann wohl kaum mehr direkt SQL-Statements absetzen

Kommt darauf an welchen Level von Abstraktion man betreibt. Z.B. könnt es in der Form sein das es eine Methode GetCustomer(const CustomerId: Integer): ICustomer gibt damit ein Customer abgefragt werden kann. Oder eine Methode GetRecordFromTable(const TableName, KeyName, KeyValue: String): TMyRecord.

Zitat von Union:

- es sei denn, man schreibt sich einen Parser und erfindet einen eigenen SQL-Dialekt, der in eigenen Table- und Query-Komponenten verwendet wird.

Oder man nimmt solche Techniken wie (N)Hibernate/ECO.

Zitat von Union:

So was nachträglich umzustellen halte ich für ziemlich aussichtslos.

Nö. Nur u.U. sehr Aufwendig. Jedoch ist es m.E. sinnvoller als jetzt das Programm nach MS SQL-Server zu trimmen und u.U. in 6 Monaten wenn ein paar Kunden kommen die sagen das sie jetzt unbedingt Oracle wollen und dann alles nach Oracle umzubauen.
ich denke spätestens dann ist eine Kapslung einfacher und schneller zu realisieren.