Von Access zu MSSQL

[Morphie]

Also es verhält sich genauso, als wenn man direkt auf die Datenbank zugreift, für Lese -und Schreibvorgänge. Wie meinst du das, ob die Verknüpfungen existieren? Anbesten du probierst das mal an nem kleinen Beispiel aus...

[Peinhard]

Zitat:

Zitat von Bernhard Geyer

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.

Ich hatte auch an anderer Stelle schon einmal nachgefragt, welche das sein sollten? Beide sind doch nur TADODatasets mit fest eingestelltem CommandType und einem 'Alias' für CommandText, der jeweils zusätzliche Code beschränkt sich auf einige wenige und nicht gerade 'anspruchsvolle' Zeilen.

[Bernhard Geyer]

Zitat:

Zitat von Privateer3000

Du meinst damit die Eigenschaft CursorLocation?!

Ja

Zitat:

Zitat von Peinhard

Ich hatte auch an anderer Stelle schon einmal nachgefragt, welche das sein sollten? Beide sind doch nur TADODatasets mit fest eingestelltem CommandType und einem 'Alias' für CommandText, der jeweils zusätzliche Code beschränkt sich auf einige wenige und nicht gerade 'anspruchsvolle' Zeilen.

Kann schon sein das in neueren Delphi-Versionen das nicht mehr ist. "In den guten Alten" D5-Zeiten könnte das noch gewesen sein.

[Peinhard]

Zitat:

Zitat von Bernhard Geyer

Kann schon sein das in neueren Delphi-Versionen das nicht mehr ist. "In den guten Alten" D5-Zeiten könnte das noch gewesen sein.

'Konstruktion' und Code haben sich zwischen D5 (ADODB Patch 2) und D2007 praktisch nicht geändert, nur das 'vergessene' Property CommandTimeout wurde irgendwann zwischen D5 und D7 noch hinzugefügt. Dafür aber hat TADODataset selbst nach wie vor einige Bugs und 'Versäumnisse', weshalb ich persönlich mit einem Abkömmling von TBetterADODataset arbeite, dem ich übrigens ua wg 'Migration' auch die TQuery-spezifischen Eigenschaften und Methoden nach 'Borland-Muster' hinzugefügt habe - ohne dass ich deswegen irgendwelche 'Risiken und Nebenwirkungen' festgestellt hätte. Ich möchte daher anregen, das generelle Abraten insbesondere von TADOQuery in's 'Reich der Legende' zu verbannen - das einzige, was sich mE hier zugunsten von TADODataset sagen liesse, ist, dass die Syntax näher an der nativen ADO-Nomenklatur ist. Gegen TADOTable hingegen lässt sich immerhin sagen, dass ein 'SELECT *' von wenigen sehr begrenzten Ausnahmen abgesehen einfach keine adäquate Zugriffsmethode darstellt.

[Privateer3000]

Sollte ich tatsächlich nur mit Datasets arbeiten
stellt sich die Frage, wie unter Datasets SQLstrings
gesendet werden. Da die Datasets kein ExecSql ausführen können.
Ich hab auch nichts vergleich bares gefunden, ausser Append und Post.
Und wie kann man den Commandtext umbrechen, wie bei querys mit add()?

[Bernhard Geyer]

Zitat:

Zitat von Peinhard

Ich möchte daher anregen, das generelle Abraten insbesondere von TADOQuery in's 'Reich der Legende' zu verbannen - das einzige, was sich mE hier zugunsten von TADODataset sagen liesse, ist, dass die Syntax näher an der nativen ADO-Nomenklatur ist.

Werd ich mir merken. Evtl. wars ja eher damals so gemeind. Mittlerweile ist bei uns ADO in Form von AdoExpress/dbGo auch vorbei da unser ADO-DB-Zugriff in unserer Bridge-Pattern-Implementierung direkt auf den ADO-Interfaces aufsetzt.

[Peinhard]

Was sicher nicht die schlechteste Lösung ist. ;)

@Privateer: es spricht aus meiner Sicht und wie gesagt nichts dagegen, bei TADOQuery zu bleiben - wenn man nicht gleich direkt aufsetzen will. Ansonsten: CommandText nimmt nur 'ganze' Strings, und der adäquate Ersatz für ExecSQL wäre, TADOCommand direkt zu verwenden (selbiger werkelt unter der Haube auch im TADODataset und Nachfahren).

[Privateer3000]

Soweit denke ich ist meine Frage beantwortet
Vielen Dank an alle.

Nur eines ist mir noch nicht ganz klar,
wie das mit den User-mdb und verknüpfung
zustande kommt

Zitat:

Zitat von Morphie

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.

Dabei meine ich wie das von Haus aus gemacht wird ohne das der eigentliche User
damit konfrontiert wird und MSAccess zu Hilfe nehmen muss.
Wäre schön wenn das veranschaulicht werden könnte.

Nochmals Danke an alle

[Morphie]

wenn ich mich von gestrigen abend erholt habe, kann ich dir gern' ein Beispielprojekt geben.
Haben es zwar in VB mit ADO gelöst, aber das sollte ja kein Problem sein...

ich meld mich später ;)

[Privateer3000]

Hallo Gemeinde ,
da dieses Thema immer noch für mich steht,
möchte ich mal vorsichtig nachfragen ob
nicht jemand ein Lösungsansatz für mich hat.
Wie verknüpfe ich diese Tabellen so dass jeder
User "seine" mdb hat aber diese mit einer
Haupt-mdb abgeglichen wird? So das nur
in der Haupt-mdb allgemeingültige (Statistik)
Daten sind?

Grüße