allgemeine Frage zu ADO

[Patrick Sack]

<br>Hi,...
<br>
<br>(Delphi5 und MS SQL Server7)
<br>
<br>1)wenn ich ein SQL Statement auf dem Server (im Enterprisemanager) ausführen und die Datenfelder editieren kann so muß das doch auch funktionieren, wenn das SQL Statement in ein TadoDatSet kopiert wird oder?
<br>
<br>Auf der Delphiseite erhalte ich leider immer die Fehlermeldung "Zu wenig Schlüsselinformationen zum aktualisieren". Die verknüpften Tabellen in dem SQL Statement besitzen beide einen Primärschlüssel.
<br>
<br>2) Kann man auf der Delpiseite nicht in irgend einem Objekt defenitiv festlegen, das dieses oder jenes Feld ein Primärschlüssel ist? Und wenn Delphi dann Daten aktualisiert weiß es genau welches der Primärschlüssel ist und welches nicht.
<br>
<br>MfG
<br>PS

[BlueBit]

Hallo,

eine Afrage muss nicht immer eine Schlüsselinformation beeinhalten, wenn Du z.B. die gespeiocherte Prozedur SP_Lock aufrufst, bekommst du alle aktuellen Sperren. Es handelt sich dabei nicht um Datensätze sondern um Informationen, obwohl der SQL Server Datensätzte verwendet um die Sperren zu verwalten

Select Abfragen kann man normalerweise immer aktualisieren, ich würde mal den Profiler starten um zu sehen was wirklich abläuft. Ein Refresh ist normalerweise eine erneutes Select, kann man im Profiler ablesen.

Aber leider kenne ich mich nicht so gut mit ADO aus wie Andreas K.
Naja, misst.. hätte dir gern mehr erzählt.

<pre>
Bis denn
Mathias
</pre&gt

[Patrick Sack]

<br>Hi,...
<br>
<br>danke BlueBit
<br>
<br>habe eine Erleuchtung gehabt. Nachdem ich die Cursor Location umgestellt hatte auf "clUseServer" waren all meine Probleme verschwunden.
<br>
<br>Habe jedoch ein paar Fragen zu dem Theme "clUseServer":
<br>1) kann ich nun generell bei DB Servern "clUseServer" erfolgreich verwenden oder habe ich dann mit anderen neuen, mir unbekannten Problemen zu rechnen? (bis jetzt ist noch keines aufgetreten)
<br>2) ist es Sinnvoll bei jedem TADODataSet "clUseServer" zu setzen? Wie sieht es zum Beispiel mit der DataSource von TDBLookUpComboBoxen aus?
<br>
<br>MfG
<br>P

[Bine]

Ein problem ist mir bekannt!!

Wenn du die master-detail beziehung verwenden willst, geht das nicht bei der DetailTabelle

BINE

@bluebit: Hallo :

Hallo,

bei clUseServer zeigt der Cursor normalerweise auf einen oder mehrere Datensätze, clUseServer ist sehr gut wenn du auf Tabellen mit viel Datensätzen zugreifst > 10000. Auch bei der Entwicklung von Internet Anwendungen sollte man clUseServer verwenden. clUseClient bedeutet das alle Datensätze beim öffnen zum Client transferiert werden, bei großen Datenmengen kann das sehr lange dauern. Das war aber nur die Theorie.

SQL Server und ADO sollte man clUseClient einsetzten, Aussage von Andreas K., bei größeren Datenmengen auf jeden Fall clUseServer (Anzahl Datensätze > 10000). Am besten Du verwendest nur die OLE DB Provider, ODBC Treiber sind ne Sache für sich, gerade was die Geschwindigkeit und Kompatiblität angeht. Bei Access immer clUseServer, da Access ne reine Desktopdatenbank ist, und es steht auch irgendwo beschrieben, Glaube ich.

Auch interessant für jeden der mit ADO zu tun hat, ist folgendes. Mann kann ADO fast genau so ansteuern wie im MDAC SDK beschrieben ist (VB Beispiele). In Delphi wird es nur ein wenig anders programmiert. Bin auch noch in der Lernphase, habe aber sehr interessant Beispiele von Adreas K. gelesen. Ist zwar mehr tipperei, aber man verlliert nicht den Überblick bei Problemen. Musst aber viel lesen und üben. Nach ein halben Jahr müsste man aber gut genug sein. Und man hat durch das SKD nen super Handbuch. LEIDER MIT VB Beispielen

Naja, Übung macht den Meister.

@Bine: Na kleene, alles im Griff

<pre>
Bis dann
</pre&gt

[Andreas Kosch]

Hallo,

beim SQL Server 7/2000 sollte man generell <b>clUseClient</b> verwenden und somit auf die Hilfe des Client-Seitigen RecordSet-Objekts zurückgreifen. Nur dann, wenn die Anzahl der Datensätze in der offenen Datenmenge (nicht die Anzahl der Datensätze in der Tabelle) sehr groß wird, sind die Nebenwirkungen von clUseServer vertretbar. Aber in der Regel wird die Anzahl der Datensätze in der Datenmenge über eine geeignete WHERE-Einschränkung begrenzt, so dass clUseClient sinnvoller ist.

Das Umschalten auf <b>clUseClient</b> bewirkt, dass ADO nicht mehr direkt auf die Datenbank zugreift, sondern statt dessen den OLE DB Service <b>RecordSet</b> dazwischenschaltet. Somit wird eine lokale Kopie der Daten auf dem eigenen Rechner bearbeitet, d.h. man darf die Verbindung zur Datenbank trennen (RecordSet als Datei speichern, Rechner ausschalten, Rechner einschalten, Daten aus der Datei laden, editieren, Netzwerkverbindung herstellen und mit einem Methodenaufruf ADO dazu bringen, alle Arbeiten mit der Datenbank abzugleichen).

Wenn die Datenmenge einer Verknüpfung mehrerer Tabellen (JOIN) über das RecordSet-Objekt (clUseClient) editiert werden soll, muss ADO immer dann geholfen werden, wenn beide Tabellen gleiche Spaltennamen verwenden, der JOIN jedoch nur eine Spalte zurückliefert. In diesem Fall kann ADO die Umsetzung nicht automatisch erledigen, so dass die Eigenschaft <b>Unique Table</b> gesetzt werden muss. Angenommen, es wird die folgende SELECT-Abfrage verwendet:
<pre>
SELECT m.ID, m.Name, d.MasterID, d.eMail
FROM TBL_MASTER m JOIN TBL_DETAIL d ON d.MasterID = m.ID
ORDER BY m.Name
</pre>
Wenn nun das eMail-Feld aus der Detail-Tabelle editierbar sein soll, kann dies <b>nach</b> dem Öffnen der Datenmenge über die Eigenschaft <b>Unique Table</b> des RecordSet-Objekts angemeldet werden:
<pre>
procedure TForm1.ADODataSet1AfterOpen(DataSet: TDataSet);
begin
ADODataSet1.Properties['Unique Table'].Value := 'TBL_DETAIL';
end;
</pre>
Diese dynamischen Eigenschaften tauchen nicht im Objektinspektor auf, da sie je nach dem verwendete OLE DB-Provider variieren.

Neben Unique Table gibt es noch über weitere Konfigurationsparameter (ca. 80), an denen man bei Bedarf "drehen" kann. Die Eigenschaft <b>Update Criteria</b> legt zum Beispiel fest, wie ADO den zu aktualisierenden Datensatz im Bestand sucht. Und <b>Update Resync</b> definiert, welche Spalten ADO nach dem Update aktualisieren soll, um die Daten auf der Client-Seite (RecordSet-Objekt) mit den Daten auf der Server-Seite zu synchronisieren:
<pre>
uses ADOInt;

procedure TForm1.CheckBox1Click(Sender: TObject);
begin
with ADODataSet1.Recordset do
begin
Properties['Update Criteria'].Value := adCriteriaKey;
Properties['Update Resync'].Value := adResyncAll;
end;
end;
</pre>
&#10

[BlueBit]

Hallo Andreas,

das letzte Beispiel von eben scheint sehr interessant zu werden, wenn man die Sache gedanklich ein bisschen Ausbaut. Wie zum Beispiel folgendes:

<pre>
- alle veränderten Datensätze (Client und Server)
- alle gelöschten (Server)
- alle neuen (Server)
</pre>

Hast Du zufällig diesbezüglich schon einige Experimente durchgeführt, würde mich mal interessieren ob es möglich ist. Da clUseClient zu 99%
eingesetzt wird, ist man ja durch die KeySet - Einstellung leider nicht immer auf den aktuellen Stand was den Datenbestand des Servers anbetrifft.

<pre>
bis dann
Mathias
</pre&gt

[Patrick Sack]

<br>@BlueBit: Danke!
<br>Wo finde ich denn dieses <b>MDAC SDK</b>? (Unter "Hilfedateien des MS SDK" habe ich nichts gefunden.)
<br>
<br>@Andreas Kosch: Danke!
<br>
<br>1) Gibt es ernstzunehmende Nachteile bei der Benutzung von clUseServer?
In den Antworten hier kann ich keinen Nachteil entdecken (eher nur Vorteile).
<br>
<br>Ich glaube den Fehler gefunden zu haben.
<br>
<br>Es lag anscheinend an dem <b>ER Modelierer</b>. Dieser hat Beziehungen zwischen Tabellen mit TriggerScripten
implementiert. Und genau durch diese Scripte bekam ich Probleme mit clUseClient.
Nachdem die Datenbankstruktur gelöscht und komplett mit Hilfe des Enterprise Managers erstellt wurde, konnte ich zum einen wieder CLUseClient als auch den OLE DB Provider verwenden (anstatt des ODBC Providers). Siehe hier im Forum: "ADO Fehler: Die zum aktualisieren angegebene Zeile wurde nicht gefunden: Einige Werte wurden seit dem letzten Lesen geändert"
<br>
<br>2) Aber was ist wenn ich eigene Trigger Scripte erstelle? Werde ich dann wieder Probleme mit clUseClient bekommen?(Naja das werde ich mal testen, aber wenn schon jemand Erfahungen damit gesammelt hat würde ich mich über ein kleines Statement freuen)
<br>
<br>3) Der Diagrammassistent vom SQL Server gefällt mir gar nicht. Gibt es einen guten ER Modelierer, der die Datenbankstruktur so erstellt, wie es auch der Diagrammassistent macht?
<br>
<br>4) Kann ich (hier im Forum) in einer Diskusion einen Link auf eine andere setzen?
<br>
<br>@all: Danke nochmals
<br>P

[Andreas Kosch]

Hallo,

zu Frage von BlueBit: <br>
Möglich ist alles, allerdings zu welchem Preis? Wenn es sich nicht um eine Minidatenbank handelt, verursachen derartige Abfragen/Synchronisationen eine sehr hohe Server-Last. Es ist daher besser, das technische Machbare im Interesse der Performance erst gar nicht zu versuchen ;-) <br>
Ich selbst verzichte zum Beispiel bei Abfragen, die nur einen Datensatz zurückliefern, vollständig auf das RecordSet-Objekt und verwende nur noch Stored Procedures mit OUTPUT-Parametern, die auch die Transaktionssteuerung völlig intern kapseln. In diesem Fall stehen die Properties gar nicht zur Verfügung.

zur Frage 1 von Patrick: <br>
Ja - clUseServer hat bei intensiven Mehrbenutzerzugriffen verheerende Auswirkungen auf der Datenbankseite. Microsoft hat dazu eine umfangreiche Beschreibung als Word-Dokument veröffentlich (ist entweder auf der CDROM zum SQL Server 7 oder auf der Buch-CDOM zu <i>Inside SQL Server 7</i> zu finden, so genau kann ich mich nicht mehr errinnern).

zur Frage 2: <br>
Die Sache mit den Scripten kann nur durch Nebenwirkungen verursacht werden, ADO kann mit Änderungen von Spaltenwerten durch Trigger umgehen.

zur Frage 4: <br>
Habe ich noch nicht ausprobiert ;-)

zur MDAC-Frage: <br>
Das MDAC-SDK ist entweder auf den MSDN-CDROMs zu finden, auf den CDROMs vom SQL Server oder als Download unter <i>http://www.microsoft.com/data/</i>

[Patrick Sack]

Danke!

zu Antwort 2:
Aber welche Nebenwirkungen? Wenn ich nochmal einen solchen Fall habe, melde ich mich wieder. Vieleicht kann man die Nebenwirkungen dann besser sehen.

MfG
P