Delphi-PRAXiS

Delphi-PRAXiS (https://www.delphipraxis.net/forum.php)
-   Datenbanken (https://www.delphipraxis.net/15-datenbanken/)
-   -   Delphi Mehrbenutzerzugriff mit ADO und MSSQL (https://www.delphipraxis.net/24735-mehrbenutzerzugriff-mit-ado-und-mssql.html)

Peter Geyer 25. Jun 2004 12:11


Mehrbenutzerzugriff mit ADO und MSSQL
 
Hallo,

ich soll in unserer Firma ein kleines Verwaltungsprog schreiben das Multiuser fähig ist.
Eigentlich dachte ich, das das nicht soo schwer sein kann, aber weit gefehlt. Ich komme seit einer Woche irgendwie nicht weiter.
Entweder ist es so einfach, das niemand drüber spricht, oder ich bin zu doof :wall:
Ich habe halb Google auswendig gelernt, aber irgendwie war nicht das richtige dabei.
Ich hoffe bei Euch gibt es Leute die sowas schonmal gemacht haben. :?

Also, ich schreibe erstmal was ich bereits verwende und was ich schon alles Versucht habe.

Ich möchte per Delphi ADO Komponenten auf einen MSSQL2000 Server zugreifen.
Dazu verwende ich TADOConnection und TADOQuerry.
Ich habe schon oft gelesen man solle die BetterADO verwenden, allerdings ist der Download nicht zu erreichen.
Es sollte ja auch mit den eigenen Komponenten klappen.

Ich habe folgendes bereits gemacht:
Der user sieht ein DBGrid dessen Inhalt über ein Querry gefüllt wird. Nun soll man einen Datensatz doppelklicken und ein
Detailfenster erscheint wo nun die Änderungen gemacht werden können. Mit OK wird das Fenster geschlossen und die Daten geschrieben. Die Prozedur mit der ich die Daten schreiben sieht folgendermaßen aus:

Delphi-Quellcode:
procedure Datenupdaten;
begin
 
  Form1.ADOConnection1.BeginTrans;
  try
  With Form1.Artikel do
    Begin
    SQL.Text:='UPDATE Artikel SET
                      ArtNr=:_ArtNr,
                      ArtName=:_ArtName
               WHERE ID=:_ID';

    Prepared := True;
    With Parameters Do
    Begin
      ParamByName('_ArtNr).Value := Form_Arikel.Edit1.Text
      ParamByName('_ArtName).Value := Form_Artikel.Edit2.Text;
    End;
    Form1.QKunde.ExecSQL;
    end;
    Form1.ADOConnection1.CommitTrans;
  except
    on E: Exception do Form1.ADOConnection1.RollbackTrans;
  end;
  Form_Arikel.Close;
end;
Das ganze klappt ja eigentlich schon ganz gut nur bekomme ich das Problem nicht in den Griff, das
zwei User die Detailmaske eines Artikels aufmachen,
-User1 Kaffee trinken geht
-User2 etwas ändert und speichert
-User1 zurückkommt und seine eigenen Änderungen speichert bzw. einfach nur OK drückt und die alten daten zurückschreibt.
Damit sind dann die Änderungen von 2 einfach weg. :(

Es ist übrigens ausdrücklich gewünscht, das alle User den selben Datensatz lesen können, aber nur der "erste" ihn auch ändern und speichern kann. Die anderen sollen halt dann nur "schnell was nachschauen" dürfen. Ich hoffe Ihr wisst was ich meine.

Überall im Netz finde ich Bruchstückhafte Anweisungen wie das zu lösen sei. Konkrete Codeschnipsel sind allerdings immer Fehlanzeige. Auch die OH von delphi und MSSQL geben nur wenig Aufschluß.

Die Möglichkeit der Sperrtabelle finde ich recht unelegant, da muss der Zeitstempel ein Verfallsdatum haben damit nach einem Absturz der Datensatz nicht ewig gesperrt bleibt und so weiter...

Ich habe auch schon etwas von
SQL-Code:
SELECT ... FOR UPDATE
gelesen, nur scheint das nur mit MySQL zu laufen.
Bei MSSQL gibt es einen Fehler der besagt das es nur in Verbindung mit CURSOR möglich sei. - Hmmpf.

An anderer Stelle wurde gesagt das das innerhalb der UPDATE Klausel geht, etwa so:
SQL-Code:
UPDATE Tabelle
SET   SpalteA = 1,
       SpalteB = 2
WHERE SpalteA = 'Alte Daten von A'
AND   SpalteB = 'Alte Daten von B'
So würde nur ein Update geschehen wenn sich die Daten in der Zwischenzeit nicht geändert hätten, und eine Exeption ausgelöst sofern die Daten nicht eingefügt wurden. Ich weiss nur nicht wie das gehen soll :cry:

Ich bin total verzweifelt, weil ich nirgendwo mal ein echtes stückchen Code, oder Anleitung finden konnte, die ich hätte adaptieren können.

Bin ich denn der einzige Mensch der dieses Problem hat? Es gibt doch tausende von Multiuser Anwendungen die genau so funktionieren.

Ich würde mich riesig freuen, wenn jemand mir da weiterhelfen könnte. Oder mir auch sagen, das ich so wie ich das vorhabe, auf dem Holzweg bin.

Wenn keiner ein Stück Code hat, gibt es vieleicht gute Bücher die das Problem konkret beschreiben? Ich habe hier schon einen Stapel, aber die sprechen mit Vorliebe über Interbase...

Bitte, bitte, bitte, ich brauche eine :idea:


in diesem Sinne

grüße Peter


:dp: :dp: *schleim* :zwinker:

Bernhard Geyer 25. Jun 2004 13:07

Re: Mehrbenutzerzugriff mit ADO und MSSQL
 
Hallo Namenskollege,

vieleicht bringt dir ja der Beitrag Wie richtig mit Transaktionen und ADO umgehen? auf ein paar gute Ideen.

neolithos 25. Jun 2004 13:16

Re: Mehrbenutzerzugriff mit ADO und MSSQL
 
Man könnte ja auch ein weiteres Attribut in die Entität einfügen, in dem du einen Wert setzt in dem du den Datensatz logisch sperrst.

Wichtig ist das du dabei Transaktionen verwendest, damit bei einem Rechner/Programm-Abstürz nicht der DS für immer gesperrt bleibt.


[EDIT/WICHTIG] Herzlich Willkommen in der DP

Peter Geyer 25. Jun 2004 14:11

Re: Mehrbenutzerzugriff mit ADO und MSSQL
 
@ Bernhard

Hallo, das ist ja witzig :-D
Soo häufig ist der Nachname jetzt ja nun auch nicht. Aber ich komme aus Kiel, bei Dir hört sich das eher nach Süden an...

Ja, Hmmm, ich hab den Beitrag schon gelesen, nur irgendwie hatte der mich auch nicht so richtig weitergebracht.
Denn die endgültige Lösung gibt´s dort auch nicht.

@neo
:wiejetzt:
ich oute mich auch gerne als >Dummer Sack<, aber ich hab nicht wirklich viel verstanden von dem was Du geschrieben hast.

Ausser natürlich
Zitat:

Herzlich Willkommen in der DP
Dankeschön :bounce1:

Wie mach ich denn nu weiter?
Soll ich meinen Code verbrennen, oder kann ich damit noch was reißen?

danke und Grüße

Peter

Jelly 25. Jun 2004 17:25

Re: Mehrbenutzerzugriff mit ADO und MSSQL
 
Hallo Peter,

google doch mal nach Bei Google suchenpessimistic lock mssql...

Gruß,
Tom

Bernhard Geyer 25. Jun 2004 18:13

Re: Mehrbenutzerzugriff mit ADO und MSSQL
 
Zitat:

Zitat von Peter Geyer
Hallo, das ist ja witzig :-D
Soo häufig ist der Nachname jetzt ja nun auch nicht. Aber ich komme aus Kiel, bei Dir hört sich das eher nach Süden an...

Stimmt, H'aurach liegt ein paar Kilometer nördlich von Nürnberg
Zitat:

Zitat von Peter Geyer
Ja, Hmmm, ich hab den Beitrag schon gelesen, nur irgendwie hatte der mich auch nicht so richtig weitergebracht.
Denn die endgültige Lösung gibt´s dort auch nicht.

Aber Ansätze wie man das Problem lösen könnte.

neolithos 25. Jun 2004 18:23

Re: Mehrbenutzerzugriff mit ADO und MSSQL
 
Erstmal enttschuldigung, war kurz vorher bei der DB-Vorlesung an der Hochschule.

Zitat:

Zitat von neolithos
Man könnte ja auch ein weiteres Attribut in die Entität einfügen, in dem du einen Wert setzt in dem du den Datensatz logisch sperrst.

Attribut = Spalte, Feld
Entität = Tabelle

Mit Logisch Sperren meine ich du setzt einfach einen Wert für, ist gerade in Bearbeitung!

Ich hoffe das ist jetzt klarer.

Generalissimo 25. Jun 2004 19:52

Re: Mehrbenutzerzugriff mit ADO und MSSQL
 
Da muss man nicht erst in einer Tabelle was setzten.
Du musst die jenige Transaktionseistellung wählen die jedem Leserechte gibt, aber nur dem jenigen, der als erster zugreift auch Schreibrechte genehmigt. Leider hab ich keine Ahnung wie das bei ADO hies. LockOptimistic oder so.
Beim Interbase heisst die Einstellung Snapshot Table Stability (Nur-Lesen Tabellenstabilität)

Robert_G 25. Jun 2004 21:02

Re: Mehrbenutzerzugriff mit ADO und MSSQL
 
Zitat:

Zitat von Generalissimo
Da muss man nicht erst in einer Tabelle was setzten.
Du musst die jenige Transaktionseistellung wählen die jedem Leserechte gibt, aber nur dem jenigen, der als erster zugreift auch Schreibrechte genehmigt. Leider hab ich keine Ahnung wie das bei ADO hies. LockOptimistic oder so.
Beim Interbase heisst die Einstellung Snapshot Table Stability (Nur-Lesen Tabellenstabilität)

Sorry, aber das war Käse.

Die Problematik ist ja eigentlich folgende:
Ernie & Bert arbeiten beide am gleichen Projekt.
Dabei halten sie sich aber meistens an verschiedenen "Ecken" der dazugehörigen Tabellen auf.

Ab & zu gibt's mächtig Zank weil Bert schon wieder Ernies Arbeit überschrieben hat ohne es zu bemerken.
Jetzt kommt Samson und baut das ein, was Generalissimo vorgeschlagen hat.
Die Folge ist, dass ENTWEDER Ernie ODER Bert arbeiten können. :arrow: Daraufhin wurden dann beide ziemlich stinkig. :mrgreen:

Kurz und knapp: Dieses extreme Sperren der Tabellen ist in der Praxis alles andere als benutzerfreundlich.

Zitat:

Zitat von Neo
Man könnte ja auch ein weiteres Attribut in die Entität einfügen, in dem du einen Wert setzt in dem du den Datensatz logisch sperrst.

Wenn ich das richtig verstanden habe, :gruebel: , mag ich es auch nicht.

Mitagspause ist zu Ende.
Ernie öffnet die Tabelle um 14:00. Bert hat sich schon 13:45 vollgefressen unter seinen Schreibtisch gequetscht.
Um 14:01 speichert Bert.
Was nun?

Ich mache es mir dabei ziemlich einfach.
In Oracle gibt es eine Pseudospalte namens RowID, die ist IMMER eindeutig (sie beschreibt schließlich die physische Position des DS auf der Fäschtpladde).
Desweiteren können sich Sessions auf 2 Arten miteinander "unterhalten":
  • Pipes - so etwas wie eine Rohrpost. Die Nachrichten werden in Echtzeit versendet und empfangen.
  • Alert flags - diese Nachrichten werden erst bei einem Commit an alle registrierten Sessions verschickt.
    :arrow: Genau die brauchen wir. (Das ist der Moment, in dem du das Gegenstück dazu für den SQL Svr suchen musst ;) )

Beim Öffnen der Tabelle hat sich Ernies Session für ein Alert flag namens "Sesam Straße" registriert.
An der Tabelle sitzt ein before-Update Trigger, der für jeden geänderten Eintrag ein Flag mit der RowID verchickt.
Als Berts Session jetzt ein Commit absetzt bekommt Ernie mit, dass sich 3 Einträge geändert haben.
Diese 3 Einträge kann man jetzt abfragen und mit der derzeitigen Ansicht synchronisieren. (unter .Net ist das ein 3-Zeiler, unter Delphi32 wird's ein Krampf ;) ).

Bei Überschneidungen kann Ernie jetzt PRO Eintrag gefragt werden, ob er seine lokalen Änderungen verwerfen, oder lieber Berts Eintrag überschreiben will.

So, mein Oraclekrempel ist gerade fertig geworden (in der Langeweile wurde aus dem Post glatt 'ne Episode Sesam straße :lol: )

OT:
Das ist ein schreibfähiger Cursor in Oracle :mrgreen:
SQL-Code:
SELECT ... FOR UPDATE
Interessant wird es mit der Erweiterung...
SQL-Code:
SELECT ... FOR UPDATE NOWAIT
Dann springt er dir in dem befürchteten Fall sofort ins Gesicht. (Aber ohne die fancy Möglichkeiten die eine Kommunikation zwischen den Sessions ermöglicht. ;) )

Peter Geyer 26. Jun 2004 12:10

Re: Mehrbenutzerzugriff mit ADO und MSSQL
 
Moin, danke erstmal für die vielen Vorschläge,

Zitat:

Zitat von Bernhard Geyer
Aber Ansätze wie man das Problem lösen könnte.

Ja, Ansätze. Aber nicht so viel darüber hinaus. Ich meine das jetzt nicht böse (wie auch :shock:)
aber wenn ich fragen würde wie ich in ein Edit etwas reinschreibe würde als Antwort kommen:
Delphi-Quellcode:
Edit1.text:='Herr Bert';
Klar das ist ja auch einfach :roteyes:


Es will einfach nicht in meinen Kopf das, Delphi, ADO und MMSQL für dieses
"wirklich seltene und fast nie vorkommende" Problem keine Lösung in der Tasche hat. :twisted:

@Robert

Danke für die wirklich schöne Sesamstraßen Episode :thuimb: Genau von dem beschriebenen Problem habe ich gesprochen. 8)
Zitat:

Zitat von Robert_G
Dann springt er dir in dem befürchteten Fall sofort ins Gesicht. (Aber ohne die fancy Möglichkeiten die eine Kommunikation zwischen den Sessions ermöglicht. )

könntest Du das nochmal genau erklären? Ich fürchte nämlich das die Kommunikation zwischen den Sessions wirklich ein Krampf werden.
Die
SQL-Code:
SELECT ... FOR UPDATE
ist irgendwie anders bei MSSQL gelöst. Wenn ich so ein Statement schreibe kommt als Fehlermeldung, das
die FOR..UPDATE Clausel nur in Verbindung mit Declare Cursor erlaubt ist.

:?: Kennt jemand die genaue Verwendung der FOR UPDATE bei MSSQL :?:


danke an alle

Peter

Generalissimo 26. Jun 2004 13:20

Re: Mehrbenutzerzugriff mit ADO und MSSQL
 
@Robert_G: Vielleicht verstehen wir uns falsch, aber gehst du davon aus die ganze Zeit ne Transaktion offen zu halten??
Sprich Ernie fängt an und öffnet ne Transaktion und beendet sie erst Stunden später?? Dies sollte man eh nicht
machen. Transaktionen sollten so kurz wie möglich offen gehalten werden.

Es können doch beide arbeiten. Es werden doch von Ernie nur die Datensätze gesperrt auf die er auch zugreift. Bert kann doch wunderbar die anderen ungelesen Datensätze verändern. So ne Transaktionseinstellung geht doch nicht auf ne ganze Tabelle (was man auch machen kann) sondern nur auch die angeforderten Datensätze. Beider können arbeiten.

Zudem ist das von mir oben genannte ist nicht radikales sperren. Dies wäre wenn der erste alle Rechte hat und der nachfolgende gar kein Zugriff mehr erhält.


Der Käsemann :freak:

Bernhard Geyer 26. Jun 2004 14:09

Re: Mehrbenutzerzugriff mit ADO und MSSQL
 
Zitat:

Zitat von Peter Geyer
Es will einfach nicht in meinen Kopf das, Delphi, ADO und MMSQL für dieses
"wirklich seltene und fast nie vorkommende" Problem keine Lösung in der Tasche hat. :twisted:

Es gibt halt für diese Problem keine allgemeingültige Lösung. Je nach Anzahl der Benutzer, der Rount-Trip-Delay-Zeit, der Anzahl der Änderungen pro Zeiteinheit, ... ist die eine oder ander Lösung geeigneter.

Selbst habe ich schon mal eine Lösung auf Basis einen "Lockservers" realisiert.
Wird ein Datensatz zum evtl. bearbeiten geöffnet, so wird der Lockserver angefragt. Erhält der User die Erlaubnis den Eintrag zu sperren, so wird der Dialog im Änderungsmodus geöffnet. Jeder weitere User erhält auf seine Anfrage eine vermerk, das der Datensatz schon zum bearbeiten geöffnet ist.

Das Problem mit evtl. abstürzenden Clients ist nicht gegeben, da der Server ein DCOM-Objekt war, und DCOM per "Ping" die existenz der Clients abfrägt und bei nicht mehr erreichen diesen die Sperre zurücknimmt.

Eine Alternative wäre z.B. auch für jede Tabelle eine Zeitstempel-Spalte einzuführen. Damit könnte relativ einfach ohne Serverkomponente vor einem Schreiben gechecket werden, ob sich der Datensatz geändert hat (Der vergleich mit allen Spalten ist problematisch, wenn BLOB/Binary-Felder ins Spiel kommen).

Sperren auf DB-Ebene ist immer Schlecht, da vor allem beim MS-SQL-Server u.U. auch reine Lese-Abfragen gesperrt werden.

Robert_G 27. Jun 2004 14:07

Re: Mehrbenutzerzugriff mit ADO und MSSQL
 
Zitat:

Zitat von Generalissimo
@Robert_G: Vielleicht verstehen wir uns falsch, aber gehst du davon aus die ganze Zeit ne Transaktion offen zu halten??

Jupp, wir haben uns falsch verstanden. ;)

Ein Alert flag würde niemals abgeschickt werden, wenn die Transaktion nicht mit einem Commit abgeschlossen wird.

Von Table locking auf record ebene halte ich persönlich nicht viel.
Selbst wenn sich mehrere Sessions mit alert flags oder pipes zuschieben, ist die allgemeine Performance WESENTLICH höher als bei ständiger Prüfung, ob ein Record gesperrt wurde oder nicht.

Nachtrag:
Zitat:

Zitat von Peter Geyer
Der Käsemann :freak:

Sorry, das war absolut nicht böse gemeint.

Zitat:

Zitat von Bernhard
Sperren auf DB-Ebene ist immer Schlecht, da vor allem beim MS-SQL-Server u.U. auch reine Lese-Abfragen gesperrt werden.

Das sehe ich ganz anders. Ich finde das sämtliche Logik, die in der DB realisiert werden kann, auch genau dorthin gehört.
Dein DCOM- Server klingt verdammt interessant, dürfte aber IMHO für wesentlich mehr Roundtrips sorgen als eine Kommunikation auf DB-Ebene.
Im neuen Entwickler gibt es einen Artikel über eMail-Benachrichtigungen bei betimmten Events auf dem SQL Svr. -> Es _MUSS_ also auch dort eine Möglichkeit zur sessionübergreifenden Kommunikation geben. (MS ist sowieso schon seit langem dabei sämtliche fancy Features von Oracle für ihren Spross zu kopieren. ;) )

Über die Sinnlosigkeit des Sperrens bei einem SELECT habe ich mich, glaube ich, schon in einem anderen Thread ausgelassen. ;)

Nachtrag:
Wenn man sämtliche Logik vom DB-Server auslegern würde, wären Datenbanken wie der SQL Svr, Oracle, Caché oder PosGreSQL (BTW die ist ein genialer Geheimtipp für alle Geizhälse mit dem Anspruch auf eine "richtige" DB) witzlos und wir könnten alle mit "Billigkram" wie mySQL, Paradox, MS Jet und Konsorten arbeiten.

Zitat:

Zitat von Peter Geyer
Ich fürchte nämlich das die Kommunikation zwischen den Sessions wirklich ein Krampf werden.

Das glaube ich nicht.

Ich weiß nicht wie es bei euch "SQL Svr"'lern implementiert ist. Aber ich denke es ist auch dort möglich sich für eine Art Event/Benachrichtigung oder sonstwas zu registrieren.

Wenn es kein Gegnstück zu Oracle's RowID gibt, musst du fix die PrimKeys der Tabelle in den Trigger schreiben (oder eine SP basteln, die das für dich erledigt ;) ).

Ansonsten hast du dann pro Tabelle einfach einen Trigger der Before Update, Before Insert und Before Delete feuert. Er muss dir jetzt nur den Schlüssel des DS liefern (wenn es keine Gegenstück zur RowID gibt, auch den Tabellennamen). Eine Möglichkeit, wie du im Programm darauf reagieren kannst, habe ich dir weiter oben schon vorgeschlagen.
Das Ganze wird in ein paar Stunden Bastelei und theorie ausarten, aber das Ergebnis wäre eine Chance, dieses Problem elegant, ohne Zusatzserver zu umschiffen. (Bei mir klappt es einwandfrei, sogar bei "bösen" Bulk DML Statements mit 5-stelligen DS-Zahlen)

Bernhard Geyer 27. Jun 2004 16:17

Re: Mehrbenutzerzugriff mit ADO und MSSQL
 
Zitat:

Zitat von Robert_G
Das sehe ich ganz anders. Ich finde das sämtliche Logik, die in der DB realisiert werden kann, auch genau dorthin gehört.
Dein DCOM- Server klingt verdammt interessant, dürfte aber IMHO für wesentlich mehr Roundtrips sorgen als eine Kommunikation auf DB-Ebene.
Im neuen Entwickler gibt es einen Artikel über eMail-Benachrichtigungen bei betimmten Events auf dem SQL Svr. -> Es _MUSS_ also auch dort eine Möglichkeit zur sessionübergreifenden Kommunikation geben. (MS ist sowieso schon seit langem dabei sämtliche fancy Features von Oracle für ihren Spross zu kopieren. ;) )

Sicherlich könnte man möglichst viel Logik auf DB-Ebene verlagern. Als ich mein Programm für den MS-SQL-Server entwickelt hatte, war für das Projekt die Version 6.5 relevant. Und dort gibt es sowas wie Ebentbenachrichtigung nicht. Auch waren die Rountrips für das damalige Projekt nicht relevant, das maximal bis zu 20 User in einem Deutschlandweiten Netz darauf zugriffen.
Aktuell bin ich an einem Projekt welches DB-Unabhänig laufen soll (MS-SQl, Oracle, MySQL, ...). Und dort kann man solche Features wie Eventbenachrichtigung nicht einbauen. Man ist schon froh wenn sich die DB's im Standard-SQL nicht zu sehr unterscheiden (Blobs, Sperrverhalten, ...).

ChristofSch 28. Jun 2004 10:00

Re: Mehrbenutzerzugriff mit ADO und MSSQL
 
Also ich löse das immer so.

1. Neue Transaktion starten
2. Gleichzeitig einen Timer aktivieren, der Timer fängt bei jedem on Change Erreignis von vorne an.
3. Wenn der Timer ausgelöst wird mache ich ein Rollback

Wenn ein User nun zum Mittag geht wird seine Transaktion durch den Timer gecancelt.

2 User können eh nicht am gleichen Datensatz arbeiten.

Gruß
Christof

taran_seven 3. Jul 2004 23:34

Re: Mehrbenutzerzugriff mit ADO und MSSQL
 
Zitat:

Zitat von Peter Geyer
Hallo,
Das ganze klappt ja eigentlich schon ganz gut nur bekomme ich das Problem nicht in den Griff, das
zwei User die Detailmaske eines Artikels aufmachen,
-User1 Kaffee trinken geht
-User2 etwas ändert und speichert
-User1 zurückkommt und seine eigenen Änderungen speichert bzw. einfach nur OK drückt und die alten daten zurückschreibt.
Damit sind dann die Änderungen von 2 einfach weg. :(

Es ist übrigens ausdrücklich gewünscht, das alle User den selben Datensatz lesen können, aber nur der "erste" ihn auch ändern und speichern kann. Die anderen sollen halt dann nur "schnell was nachschauen" dürfen. Ich hoffe Ihr wisst was ich meine.

Ein Trick wäre: Beim wechseln in den Edit-Modus einen Timer setzen, der regelmäßig automatisch speichert.
Ebenso vor "BeforeEdit" ein Refresh aufrufen um vor dem eintippen des ersten Zeichens die aktuellen Daten zu sehen.


Leider sind die ADO-Datasets sehr fehlerhaft... Der LockTyp=Pessimistic den Du bräuchtest geht nicht, weil er sich immer auf BatchOptimistic stellt. Auch die DBExpress ist mit MS-SQL2000 nicht wirklich glücklich...
Am besteh geht es mit Firebird... nur leider habe ich Merge-Replikation mit Laptops gebraucht und das kann nur MS-SQL wirklich gut. (vor allem ohne großen Programmieraufwand)


Alle Zeitangaben in WEZ +1. Es ist jetzt 19:04 Uhr.

Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz