Probleme mit BDE-SQL-Links-Treiber

[Anton Zürner]

Hallo,

wir stellen gerade ein Delphi 4/INTERBASE-Projekt auf MS-SQL-Server 7.0. Warum werden bei den BDE-SQL-Links-Treibern für MS-SQL die Memos nur als String-Felder mit 255 Zeichen erkannt, während bei den ODBC-Treibern die Felder korrekt als Memos erkannt werden ?? Liegt hier eine falsche Einstellung bei den SQL-Links-Treibern vor oder gibt es eine neuere Version.

Mfg Anton Zürner

[Bernhard Geyer]

Auf einen MS-SQL-Server 7.0 sollte man nicht mehr mit den BDE-SQL-Links zugreifen, da diese nur für die Version 6.5 erstellt und getestet wurden und für die Version 7.0 es keine neuere Version mehr geben wird, da MS als zukünftigen Zugriffsweg auf Daten die ADO-Schnittstelle propagiert. (Wurde auch schon mal in diesem Forum angesprochen)

Falls man den Schritt auf ADO scheut, so kann man m.E. auch mit den ODBC-Treibern ganz gut zurechtkommen. Man hat zwar nur über ODBC die Funktionalität einer Version 6.5 zur Verfügung (Neue Features werden nur über ADO unterstützt), aber falls man diese nicht benötigt, kommt man auch mit ODBC zurecht (haben selbst eine Applikation mit MS-SQl 7.0 über ODBC und Delphi (4

[Kai Möller]

Hallo,

mich würde einmal interessieren, warum gerade von Interbase auf MSSQL umgestellt wird???

Wenn es ein echtes Upsizing sein soll, würde ich nur auf ORACLE gehen. Dafür gibt es außer SQL-Links auch gute 3rd Party Komponenten für schnellen Zugriff.

Gruß Ka

[Andreas Kosch]

Hallo,

seit Februar 2000 ist ORACLE - was den absoluten Transaktionsrekord angeht - nur noch 2. Wahl (wobei es bei diesem Test auf Leistung und Skalierbarkeit, aber nicht so sehr auf maximale Datenbankgrösse ankam). Nummero Uno ist der Microsoft SQL Server 2000 (Beta) unter Windows 2000 ;-)

Für den MS SQL Server 7 gibt es eine ganze Reihe von Gründen: <br>
- MSDE als "kostenlose" Version für bis zu 4 Benutzer <br>
- besseres Preis/Leistungsverhältnis als ORACLE<br>
- einfacheres Handling als ORACLE <br>
- bessere Integration in ADO und COM+ <br>
Mit der 7er Version sind leider fast alle Nachteile der 6.5er-Version entfallen, so dass man den SQL Server 7 nicht mehr so einfach ignorieren kann ;-)

&#10

[Bernhard Geyer]

Mit SQL-Server sind <b>nicht alle</b> Nachteile der SQL-Datenbank entfallen! So kann man mit dem SQL-Server z.B. kein kaskatiertes Löschen auf DB-Ebene realisieren. Man muß auf selbstgeschriebene Trigger zurückgreifen und die Referenzielle Integritäts-Überprüfung von Fremdschlüsseln aufheben und alles über Trigger realisieren. Dies führt aber leider dazu, daß die Performance bei Verwendung von Trigger evtl. sehr in die Knie geht! (Ist schon Komisch das dieses kaskatiertes Löschen die "kleine" MS-ACCESS-Datenbank unterstützt, der "große" SQL-Server dies jedoch nicht!

[Andreas Kosch]

Hallo,

meiner Auffassung nach <b>sollte</b> kein SQL-Server das kaskadierte Löschen unterstützen, denn die referenzielle Integrität ist in meinen Augen ein <b>Sicherheitsnetz</b>. So wie niemand am Auto einfach so den Airbag abschalten kann, sollte auch diese Prüfung nicht deaktiviert werden. Es kommt häufig vor, das man von Hand über SQL am Datenbestand repariert. Wenn man nun einen Hauptdatensatz löschen will, <b>sollte</b> hier eine Warnung kommen, wenn es Details gibt. Es ist in meinen Augen verheerend, wenn die Datenbank automatisch auch dann alle Detaildatensätze mit abräumt, wenn man nur einen Datensatz löschen wollte ;-)

Aus diesem Grund würde ich auch keinen Trigger einsetzen, sondern die Löschaktionen entweder a) aus einer Stored Procedure oder b) direkt aus dem Client heraus in der richtigen Reihenfolge aufrufen.

Das ist aber nur meine eigene Meinung - die sich eventuell aus entsprechenden schmerzlichen Erfahrungen herausgebildet hat ;-

[Bernhard Geyer]

Sicherlich habe ich in meiner Datenbank nicht überall das kaskatierte Löschen per Trigger aktiviert, sondern nur an Stellen, die ich mir überlegt habe. Hab auch Stellen in meinem Modell, in der ich dies nicht freigegeben habe und eine entsprechende Warnung beim Löschen eines Hauptdatensatzes mit Detaildatensätzen kommt.

Deine Lösung a wäre eine gute Möglichkeit (werde ich mir vielleicht bei einem neuen Projekt so überlegen, hatte aber bei meinem ersten größeren Projekt noch nicht so viel praktische Erfahrungen). Die Lösung b finde ich problematisch, da hier evtl. an mehreren Clients Änderungen vorgenommen werden müssen

[Andreas Kosch]

Hallo Bernhard,

der Weg über die Stored Procedure wird wohl am sinnvollsten sein. Denn häufig sind zusätzliche Prüfungen und Arbeitsschritte notwendig, bevor ein Datensatz gelöscht werden darf. Zum Beispiel wird geprüft, ob es für einen Kunden noch ausstehende Lieferungen/Zahlungsvorgänge gibt oder der zu löschende Datensatz soll vorher in eine Archiv-Tabelle kopiert werden usw. Von der Warte aus betrachtet könnte das kaskadierende Löschen vermutlich nur in seltenen Fällen genutzt werden