AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Thema durchsuchen
Ansicht
Themen-Optionen

ADO Guru gesucht

Ein Thema von haentschman · begonnen am 12. Mär 2013 · letzter Beitrag vom 14. Mär 2013
Antwort Antwort
Seite 2 von 5     12 34     Letzte »    
Benutzerbild von haentschman
haentschman

Registriert seit: 24. Okt 2006
Ort: Seifhennersdorf / Sachsen
5.388 Beiträge
 
Delphi 12 Athens
 
#11

AW: ADO Guru gesucht

  Alt 13. Mär 2013, 10:09
Danke nochmal...

Wir benutzen die Standard ADO vom Delphi. In meinem Falle XE. Ich habe beides ausprobiert ServerCursor, ClientCursor. (default Client) Beide hatten das gleiche Ergebnis... nach einem Post wird die Tabelle nicht aktualisiert.
  Mit Zitat antworten Zitat
Benutzerbild von Bernhard Geyer
Bernhard Geyer

Registriert seit: 13. Aug 2002
17.201 Beiträge
 
Delphi 10.4 Sydney
 
#12

AW: ADO Guru gesucht

  Alt 13. Mär 2013, 10:30
CursorLocation:=clUseServer; ist nur was für Zugriff auf Access.
Für MS SQl-Server sollte man i.d.R. cluseClient nehmen wenn man nicht teilweise sehr schlechte Performance haben will.
Windows Vista - Eine neue Erfahrung in Fehlern.
  Mit Zitat antworten Zitat
Benutzerbild von sx2008
sx2008

Registriert seit: 16. Feb 2008
Ort: Baden-Württemberg
2.332 Beiträge
 
Delphi 2007 Professional
 
#13

AW: ADO Guru gesucht

  Alt 13. Mär 2013, 10:57
Irgendwie ist mein Beitrag noch nicht richtig angekommen.
Wenn man einen Datensatz in ein TDataset (bzw. TAdoTable oder TAdoQuery) einfügt,
dann kennt nur der Datenbankserver die neue AutoInc-ID.
Im Dataset sind alle Feldwerte bekannt, denn man hat sie ja selbst vor dem Aufruf von Post befüllt,
nur das AutoInc-Feld ist leer.
Dummerweise hat das Primärschlüsselfeld das Attribut Required; d.h. das Feld muss einen Wert <> NULL haben.
Einerseits ist das PK-Feld für den neuen Datensatz leer und andererseits darf es nicht leer sein.

Man muss einfach akzeptieren, dass AutoInc-Felder für manche Anwendungszwecke "böse" sind.
Wie gesagt, wenn man einfach nur die Daten in die DB schreibt nach dem Prinzip "fire and forget", dann sind AutoInc-Felder ok.
Wenn man aber anzeigen möchte, was man gerade eingefügt hat, dann geht das nur mit Klimmzügen.
Es hat auch nichts mit ADO zu tun, sondern das Problem ist ganz grundsätzlicher Art.
  Mit Zitat antworten Zitat
jobo

Registriert seit: 29. Nov 2010
3.072 Beiträge
 
Delphi 2010 Enterprise
 
#14

AW: ADO Guru gesucht

  Alt 13. Mär 2013, 12:32
Irgendwie ist mein Beitrag noch nicht richtig angekommen.
Tja, meiner auch nicht.
Zu Deinem Beitrag würde ich allerdings anmerken, dass Du formal erstmal recht hast, die Treiber jedoch mehr beherrschen (müssen) als Du beschreibst. (Siehe bspw. die anderen Techniken, bei denen es funktioniert)
Vermutlich ist es technisch nicht überall gleich gelöst, aber es ist doch davon auszugehen, dass DB und Treiberschicht auch ohne PK eine Zeile eindeutig identifizieren können (siehe bspw. ROWID, je nach System mag das anders lauten).
Gruß, Jo
  Mit Zitat antworten Zitat
Furtbichler
(Gast)

n/a Beiträge
 
#15

AW: ADO Guru gesucht

  Alt 13. Mär 2013, 12:40
Es hat auch nichts mit ADO zu tun, sondern das Problem ist ganz grundsätzlicher Art.
Stimmt nicht. Wenn ADO wüsste, das es sich um ein IDENTITY-Feld handelt, könnte es ja den neuen Wert nach dem INSERT einfach abholen... Macht es gott-sei-dank auch

Ich würde es mal mit der Eigenschaft 'AutoGenerateValue' des persistenten Feldes versuchen. Für das Identity-Feld sollte dieser Wert auf 'arAutoInc' stehen (leider macht das ADO bzw. Delphi nicht von alleine, wenn man die Felder einliest).

Wenn dann ein neuer Datensatz gepostet wird, holt sich ADO die neue ID und trägt sie in das Feld ein. Das sollte das Problem lösen.

Geändert von Furtbichler (13. Mär 2013 um 14:47 Uhr)
  Mit Zitat antworten Zitat
grl

Registriert seit: 5. Feb 2007
174 Beiträge
 
FreePascal / Lazarus
 
#16

AW: ADO Guru gesucht

  Alt 13. Mär 2013, 13:09
Wenn der ID ein AutoIncrement und als aktiver Index eingestellt ist, müsstest du nach dem Post mit einem Refresh; Last; zum Ziel kommen.
Also, das würd ich nicht tun - wie stellst du denn da sicher, daß das DEIN letzter Eintrag ist und nicht der vom zeitgleich postenden Nachbarn?

GRL
  Mit Zitat antworten Zitat
Benutzerbild von p80286
p80286

Registriert seit: 28. Apr 2008
Ort: Stolberg (Rhl)
6.659 Beiträge
 
FreePascal / Lazarus
 
#17

AW: ADO Guru gesucht

  Alt 13. Mär 2013, 13:16
bei Oracle geht das, da wird jede ID nur einmal generiert, da wird sie allerdings Tabellenunabhängig, zentral erzeugt. (nextval)
Programme gehorchen nicht Deinen Absichten sondern Deinen Anweisungen
R.E.D retired error detector
  Mit Zitat antworten Zitat
Benutzerbild von haentschman
haentschman

Registriert seit: 24. Okt 2006
Ort: Seifhennersdorf / Sachsen
5.388 Beiträge
 
Delphi 12 Athens
 
#18

AW: ADO Guru gesucht

  Alt 13. Mär 2013, 17:27
Hallo...
Zitat:
Ich würde es mal mit der Eigenschaft 'AutoGenerateValue' des persistenten Feldes versuchen. Für das Identity-Feld sollte dieser Wert auf 'arAutoInc' stehen (leider macht das ADO bzw. Delphi nicht von alleine, wenn man die Felder einliest).
...führte nur halb zum Teilziel. AutoGenerateValue funktioniert nur mit persistenten Feldern und kann nicht zur Laufzeit gesetzt werden. TField.FieldType hat auch ftAutoInc. Den dann auf das ID Feld gesetzt und es sind die ID´s nach dem Post in der Tabelle

Soweit so gut...
Delphi-Quellcode:
Table.Append;
Table.Post; // um die ID zu kriegen ...hier ist die ID auch nun da
Table.Edit;
Table... füllen (außer ID logischerweise)
Table.Post; // --> Fehler: "Der Schlüsselwert für diese Zeile wurde in der Datenquelle geändert oder gelöscht. Die lokale Zeile ist nun gelöscht "
...Die ID ist vor dem Post exakt identisch wie vor dem Edit. Es werden nur andere Felder befüllt.

Ein Workaround der durchläuft:
Delphi-Quellcode:
Table.Append;
Table.Post; // um die ID zu kriegen ...hier ist die ID auch nun da

LastID:= Table.FieldByName('ID').AsInteger; // ID merken
Table.Close;
Table.Open;
Table.Locate('ID',LastID,[]);

Table.Edit;
Table... füllen / ändern (außer ID logischerweise)
Table.Post;
Wenn das mit dem AutoInc zu tun hat futtere ich nen Besen.
Verzweiflung, weil ich mich quälen muß.

Zitat:
Irgendwie ist mein Beitrag noch nicht richtig angekommen.
Zitat:
Tja, meiner auch nicht.
... meint ihr ich ignoriere Euch ? Im Gegenteil.

Die Frage ist doch, warum ADO so mit den AutoInc umgeht und andere Zugriffskomponenten das anders handlen. Und ein Edit + Post ist ja das normalste der Welt... nur bei ADO nicht.

Nochmal:
Ich kann weder auf Querys ausweichen noch sonst irgendwas. Ich muß mit dem Append, Post, Edit leben ! Wenn es nach mir ging wäre ADO schon von Anfang an weg gewesen. Das ADO seine Eigenheiten hat ist ja hinlänglich bekannt.

Danke an alle die sich einen Kopf machen.

Geändert von haentschman (13. Mär 2013 um 17:29 Uhr)
  Mit Zitat antworten Zitat
Benutzerbild von Bernhard Geyer
Bernhard Geyer

Registriert seit: 13. Aug 2002
17.201 Beiträge
 
Delphi 10.4 Sydney
 
#19

AW: ADO Guru gesucht

  Alt 13. Mär 2013, 17:37
Die Frage ist doch, warum ADO so mit den AutoInc umgeht und andere Zugriffskomponenten das anders handlen.
Soviel ich vor Jahren als ich Performanceprobleme untersucht habe gesehen habe ist das ADOExpress/dbGo einige Implementierungen speziell gegen Access hatte. Eigenheiten von MS SQL-Server wurde eher stiefmütterlich behandelt.

Evtl. ist das immer noch so das einfach bisher vergessen wurde die AutoInc-Felder vom MS-SQL-Server vollständig zu unterstützen.
Windows Vista - Eine neue Erfahrung in Fehlern.
  Mit Zitat antworten Zitat
Benutzerbild von p80286
p80286

Registriert seit: 28. Apr 2008
Ort: Stolberg (Rhl)
6.659 Beiträge
 
FreePascal / Lazarus
 
#20

AW: ADO Guru gesucht

  Alt 13. Mär 2013, 17:52
Die Frage ist doch, warum ADO so mit den AutoInc umgeht und andere Zugriffskomponenten das anders handlen. Und ein Edit + Post ist ja das normalste der Welt... nur bei ADO nicht.
da Du geschrieben hast, Du kommst an der Table nicht vorbei, habe ich mich bisher zurück gehalten.
Es ist doch nicht das Problem der DB-Schnittstelle, wenn eine superduper DB-Komponente es nicht auf die Reihe bringt, eine vernünftige Kommunikation mit der Datenbank einzurichten.
Zumindestens wenn man nur die Tquery nutzt (meine Erfahrung) kann man mit ADO ganz gut leben, vor allem wenn unter der gleichen Oberfäche zwei DB (oracle/MSSQL) bedient werden.
Daß das Fehlermeldeverhalten von OS zu OS durch andere Treiber ein anderes geworden ist, nervt aber Fehler werden im allgemeinen ja auch vor der Tastatur verursacht.

Gruß
K-H
Programme gehorchen nicht Deinen Absichten sondern Deinen Anweisungen
R.E.D retired error detector
  Mit Zitat antworten Zitat
Antwort Antwort
Seite 2 von 5     12 34     Letzte »    


Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 04:04 Uhr.
Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz