ADO Guru gesucht

[haentschman]

Hallo...

ich bin mit meinem Latein am Ende.

Gegeben:
- Tabelle mit "ID" als Autoinc. (PK) (der Rest ist eher uninteressant)
- gewachsenes Programm was so mit anderen DBMS gut funktioniert

IST:
1. TADOTable
2. Tabelle ist leer

Delphi-Quellcode:

Table.Append;
Table... füllen (außer ID logischerweise)
Table.Post;
Table.Refresh; // hier knallts mit Fehler... sinngemäß "Datensatz wurde geändert oder gelöscht. Die aktuelle Zeile wird gelöscht"

...eigentlich sollte das Post ja die Tabelle aktualisieren. Ich vermute, daß das bei ADO nicht funktioniert. Da auf dem Server die ID existiert und in der Datenmenge nicht und er den PK nicht zuordnen kann. An diversen Stellen konnte ich durch ein Open/Close einen Workaround hinbiegen. An anderen Stellen, wo die ID, nach dem Post, weiterverarbeitet wird geht das nicht, da der Datensatzzeiger dann auf dem ersten steht und nicht auf dem letzten Eingefügten.

Erledigt:
Dann habe ich testweise das DBFramework auf SDAC umgerüstet... keinerlei Fehler ! Leider kann ich die Entscheidung nicht selbst treffen.
Versuche mit den Properties der Connection und der ADOTable... ohne Erfolg.

Bitte:
Welche Tricks verhindern diese bescheuerten Meldungen.

:hi:

[sx2008]

Zitat:

Zitat von haentschman (Beitrag 1207150)

Tabelle mit "ID" als Autoinc. (PK) (der Rest ist eher uninteressant)

Man sollte keine AutoInc-Felder verwenden, wenn man den Wert für weitere Verarbeitung noch benötigt!

Zunächst muss man sich mal klarmachen, dass Tabellen ohne Primärschlüsselfeld nicht sicher sind, weil man einen bestimmten Datensatz nur über das eindeutige PK-Feld ändern oder löschen kann.

Code:

Farbe  | Hersteller
blau   | VW
silber | BMW
blau   | VW
grau   | Daimler

In der Beispieltabelle gibt es 2 gleiche Datensätze.
Mit SQL gibt es keine Möglichkeit (!) nur einen dieser beiden Datensätze zu verändern oder nur einen davon zu löschen!

Schlussfolgerung
Tabellen ohne Primärschlüssel sind als "defekt" zu betrachten.

Bei einer Tabelle mit einem AutoInc-Feld als PK entsteht ein Problem:
Wenn mehrere Prozess in die gleiche Tabelle Datensätze einfügen,
wie kann dann ein Prozess herausfinden welcher Datensatz von ihm ist?
Da der Primärschlüssel das einzige sichere Erkennungsmerkmal für einen Datensatz ist, der Prozess aber den PK nicht kennt ist es mathematisch für einen Prozess unmöglich seinen gerade geschriebenen Datensatz wiederzuerkennen.

Schlussfolgerung
Autoinc-Felder darf man nur einsetzen wenn man den PK eines gerade eingefügten Datensatzes nicht benötigt.
Sobald aber der PK in einen anderen Tabelle als Fremdschlüssel benötigt wird ergeben sich Probleme.
Nur weil SDAC keinen Fehler erzeugt bedeutet das nicht, dass alles in Ordnung ist.

Mögliche Auswege:
Beim SQL Server kann man z.B. die Abfrage SELECT @@Identity ausführen um den zuletzt eingefügten PK zu erhalten.

Manchmal muss man etwas nachhelfen und das Property TField.AutoGenerateValue im Code einstellen
http://docs.embarcadero.com/products...rateValue.html

[Uwe Raabe]

Zitat:

Zitat von sx2008 (Beitrag 1207156)

Mögliche Auswege:
Beim SQL Server kann man z.B. die Abfrage SELECT @@Identity ausführen um den zuletzt eingefügten PK zu erhalten.

Alternativ kann man auch die OUTPUT-Klausel verwenden:http://msdn.microsoft.com/de-de/libr...CaptureResults

[Bernhard Geyer]

Zitat:

Zitat von sx2008 (Beitrag 1207156)

Mögliche Auswege:
Beim SQL Server kann man z.B. die Abfrage SELECT @@Identity ausführen um den zuletzt eingefügten PK zu erhalten.

Die Abfrage von @@Identity ist nicht sicher wenn man mit Replikationen arbeitet. Wird auch in der MSDN beschrieben was man machen muss um Replikationssicher zu werden.

[haentschman]

Guten Morgen... :-D

...danke für eure Anteilnahme. Die Autoinc ID ist auch primary Key. Ich dachte bisher immer, daß eine Table den Inhalt der Datenbanktabelle repräsentiert. (incl. des Autoinc nach dem Post). Das scheint bei ADO nicht so zu sein.
Leider bin ich auf die Tables festgelegt, ob mir das gefällt oder nicht.
Noch ein Beispiel was in anderen DBMS funktioniert:

Delphi-Quellcode:

Table.Append;
Table.Post; // um die ID zu kriegen ... die Table sollte dann aktuell sein, normalerweise.
Table.Edit; // dann knallts hier...
Table... füllen (außer ID logischerweise)

... ich würde lieber heute als morgen diesen Kram über Bord werfen... leider wäre dafür der Aufwand zu hoch. :roll:

[Uwe Raabe]

Wenn der ID ein AutoIncrement und als aktiver Index eingestellt ist, müsstest du nach dem

Delphi-Quellcode:

Post

mit einem

Delphi-Quellcode:

Refresh; Last;

zum Ziel kommen.

[jobo]

Das Prinzip sollte schon auch unter ADO funktionieren, selbst wenn es die bereits genannten Probleme gibt. Zumindest tut es das bei mir unter Oracle. Hier wird zwar mit Trigger/Sequence der PK generiert, aber das sollte clientseitig egal sein.
Ich würde mal klären, welche Versionen du für ADO > MDAC und in Delphi verwendest.
Die MDAC Version ist je nach Systemaufbau ein Zufallsprodukt der Office Version, unter Delphi gab es immer wieder auch Updates zu ADO.
TADOTable bietet leider auch den geringsten Spielraum. Per Query kannst Du die explizite Rückgabe des PK anfordern und und und...

[Bernhard Geyer]

Zitat:

Zitat von jobo (Beitrag 1207184)

Die MDAC Version ist je nach Systemaufbau ein Zufallsprodukt der Office Version, ...

MDAC nicht. Das wird ganz normal per Windows-Update verteilt. Was du meinst ist die JET-Engine. Diese ist aber schon seit Jahren kein Bestandteil von MDAC mehr.
MDAC ist mittlerweile praktisch nur noch zur Verteilung des ADO/OLEDB, Native Clients für den MS SQL-Server zuständig.

[generic]

Was für ein Cursortyp/CursorLocation/Locktyp ist eingestellt?

Ich mach das in der Regel so wie du das beschreibst.

Code:

TADODataset
CursorLocation:=clUseServer;
.open
.Append
.Post
id := .fieldbyname('id').asinteger;
.close

Bei mir läuft ein MSSQL 2000 oder 2008r2.
Ich nutze die ADO Komponenten welche bei D2007 dabei sind.

Wenn ich mich recht erinnere, stehen die restlichen Werte auf den voreingestellten Werten.

[jobo]

@MDAC:
Ok, ich bin nicht mehr auf dem neuesten Stand. Ab Vista scheinbar automatisch an Bord als WDAC.
Welches OS vorliegt, ist ja nicht angegeben oder?

[haentschman]

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.

[Bernhard Geyer]

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.

[sx2008]

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

Delphi-Quellcode:

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.

[jobo]

Zitat:

Zitat von sx2008 (Beitrag 1207199)

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).

[Furtbichler]

Zitat:

Zitat von sx2008 (Beitrag 1207199)

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.

[grl]

Zitat:

Zitat von Uwe Raabe (Beitrag 1207177)

Wenn der ID ein AutoIncrement und als aktiver Index eingestellt ist, müsstest du nach dem

Delphi-Quellcode:

Post

mit einem

Delphi-Quellcode:

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

[p80286]

bei Oracle geht das, da wird jede ID nur einmal generiert, da wird sie allerdings Tabellenunabhängig, zentral erzeugt. (nextval)

[haentschman]

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 :thumb:

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. :roll:
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. 8-)

[Bernhard Geyer]

Zitat:

Zitat von haentschman (Beitrag 1207265)

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.

[p80286]

Zitat:

Zitat von haentschman (Beitrag 1207265)

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

[Perlsau]

@haentschman:

Wäre es nicht möglich, deiner Einfüge-Procedure eine eigene Datenbank-Komponente, z.B. ein AdoDataset bzw. ein AdoQuery zu spendieren und die dann am Ende wieder freizugeben, um danach mit einem einfachen AdoTable.Refresh die Original-Komponente zu aktualisieren?

[haentschman]

Sooo... mal ein Originalkonstrukt:

Delphi-Quellcode:

procedure WriteSort(ds: TDataSet);
    var
        i: integer;
    begin    
        for i := 0 to sl.Count - 1 do begin
            if ds.Locate('ID', Integer(sl.Objects[i]), []) then begin
                ds.Edit;
                try
                    ds.FieldByName(SortFeld).AsInteger := (i + 1) * 2;
                    ds.Post; // -> hier knallts 
                except
                    ds.Cancel;
                    raise;
                end;
            end else begin
                raise Exception.Create('Locate fehlgeschlagen für ID ' + sl.Strings[i]);
            end;
        end;
    end;

.. da das an so vielen Stellen vorkommt glaube ich langsam nicht an einen simplen Fehler.

@Perlsau:
Das geht leider nicht so einfach. Die DataSets kommen aus einem Framework und sind komplett verteilt und verknotet. Da kann man nicht einfach was umoperieren :zwinker:

Nachtrag: Inzwischen habe ich gesehen, daß Stellen, die einen Fehler produzierten, durchlaufen und andere Neue sich beschweren. Das riecht doch nach einem Grundsatzproblem !

Zitat:

'Die zum Aktualisieren angegebene Zeile wurde nicht gefunden. Einige Werte wurden seit dem letzten Lesen ggf. geändert'.

[jobo]

Wo ist da jetzt das Append?
Du bekommst ein Dataset, das offenbar in State dsbrowse ist.
In der Menge lokalisierst Du einen DS, der dann ein Update erhält.

[haentschman]

:-D Ob Append oder nicht. Es knallt entweder beim Post oder Refresh (zu anderen Gelegenheiten).

[jobo]

Falls im angegeben Beispiel die Fehlermeldung zum Quelltext passt:
Bezieht sie sich wohl eher auf das ds.Cancel (was wohl unnötig ist)
Lass das mal weg und schau Dir die Fehlermeldung an.
BTW: Geschieht das in der IDE oder bei der laufenden Anwendung?

[haentschman]

Das passiert sowohl in der IDE als auch normal.
PS: bin jetzt am Arbeitsplatz weg... kann erst morgen testen.

Frage nebenbei:
Ich habe die Idee die Tables durch anderes auszutauschen ADODataset oder Query(select *)... wie die sich verhalten. Meint ihr, daß der Aufwand lohnt ? Das geht relativ einfach, da im Framework auszutauschen.

[DeddyH]

Ich bin jetzt nicht so ADO-affin, aber ich denke, TADOTable bietet wie der Name schon sagt Zugriff auf genau eine Tabelle. Das mag bei DDL-Anweisungen ja noch angehen, für Abfragen ist das aber doch unnötig unflexibel, oder?

[haentschman]

Zitat:

TADOTable bietet wie der Name schon sagt Zugriff auf genau eine Tabelle.

...und genau das ist in diesen Fällen gewünscht mit der gesamten Datenmenge.

[DeddyH]

Das ist aber mit einem TADODataset auch machbar, man muss eben das SQL selbst definieren.

[haentschman]

Ist das auch bidirektional ?

[DeddyH]

Keine Ahnung, ich glaube aber nicht.

[haentschman]

hmmm... laut DocWiki kennt es auch Append und Konsorten... Ich probiere es einfach mal aus.

[Furtbichler]

Also ich kann das nachvollziehen, aber nur dann, wenn eine Spalte im Server über einen Trigger geändert wird. Dann bekommt es ADO nicht mit.

Folgender Befehl wird von ADO abgesetzt, wenn ich einen Datensatz in eine 'Datatable' Tabelle anhänge (das sp_executesql nehme ich mal weg):

Code:

SET NOCOUNT OFF; 
INSERT INTO "Test".."DataTable" ("text") VALUES ('Foobar'); 
SELECT SCOPE_IDENTITY() AS SCOPE_ID_COLUMN

Es wird also der Datensatz angehängt und die ID ordentlich abgeholt. Also funktioniert das auch alles. Bis hierhin.

In meiner Test-Tabelle gibt es eine weitere Spalte 'someID'. Die wird per Trigger gesetzt, und *nicht* über ADO (War zufällig so).

Nun verändere ich die Zeile in meinem Delphi-Programm: Folgender Befehl geht zum Server:

Code:

UPDATE "Test".."DataTable" 
SET "text"='BarFoo' 
WHERE "ID"=123 
AND "text"='Foobar' 
AND "someID" IS NULL --- <<<<< deswegen knallt es

ADO denkt, 'someID' sei NULL (klar, wurde von Delphi ja auch nicht geändert), aber das stimmt ja nicht (wegen meinem Trigger).

Wenn ich den Trigger entferne, funktioniert alles.

Prüf doch mal, ob der hinzugefügte Datensatz in der DB exakt die gleichen Daten hat, wie in deiner App...

[Bummi]

Ich habe mich lange zurückgehalten und muss gestehen ich kenne dieses Problem in jahrelanger Erfahrung mit ADO und MSSQL nur in 3 Fällen:
1.) man verwendet Clienseitige und Serverseitige Datasets parallel
2.) wie Furtbichler bereits anmerkte, unsauber programmierte Trigger
3.) Defaultvalues in beliebigen Spalten, welche Clientseitig nicht beschrieben werden.

[haentschman]

Guten Morgen... 8-)

1.) man verwendet Clienseitige und Serverseitige Datasets parallel
-> kann ich ausschließen. Alle DataSets sind Clientseitige

2.) wie Furtbichler bereits anmerkte, unsauber programmierte Trigger
-> wie kann ich das kontrollieren ? Die DB stammt nicht von mir. Ich kann mit dem Managementstudio drauf zugreifen. Wo finde ich das im Managementstudio ?

3.) Defaultvalues in beliebigen Spalten, welche Clientseitig nicht beschrieben werden.
-> Wo finde ich das im Managementstudio ?


Bitte habt etwas Nachsicht. Es ist mein erster MSSQL mit Managementstudio. :roll:

Danke.

Nachtrag: auch ein Wechsel auf ADODataset hat die gleichen Effekte... fast logisch, hat den gleichen Vorfahr wie ADOTable :(

[Furtbichler]

Stelle eine Verbindung im SSMS her.
Variante 1:
Dann suchst Du im Baum links die Datenbank, dann die Tabelle.
Rechtsklick auf die Tabelle => Design / Entwerfen.
Dann Felder nacheinander anklicken und unten schauen, was da so an Defaultwert eingestellt ist.

Für die Trigger gibt es unterhalb der Tabelle einen eigenen Knoten. Expandieren und schauen, was da so los ist.

Variante 2:
Rechtsklick auf die DB => Tasks => Skripte generieren => Tabelle auswählen
und dann im erzeugten Skript ('CREATE TABLE') schauen, was da so los ist.
Hier kannst Du auch die Trigger prüfen (Achtung! Vorher im Skript-O-Mat-Wizzard einstellen)

[haentschman]

Danke erst mal... 8-)

In den Tabellen gibt es eine Spalte die mit Defaultwert belegt wird. Beim Debuggen an einer ganz bestimmten Stelle für eine spezielle Tabelle habe ich aus dieser Tabelle den Defaultwert entfernt. (was ein Satz.. :lol:)

...es kracht mit der gleichen Meldung.

Das Script einer Tabelle (Namen geändert)
YYYY = Tabelle 1
XXXX = Tabelle 2

Delphi-Quellcode:

USE [YYYY] 
GO
/****** Object:  Table [dbo].[XXXX]    Script Date: 03/14/2013 10:20:06 ******/
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
SET ANSI_PADDING ON
GO
CREATE TABLE [dbo].[XXXX](
   [ID] [int] IDENTITY(1,1) NOT NULL,
   [x] [int] NULL,
   [x] [int] NULL,
   [x] [varchar](2) NULL,
   [x] [varchar](50) NULL,
   [x] [varchar](6) NULL,
   [x] [varchar](4) NULL,
   [x] [varchar](50) NULL,
   [x] [varchar](4000) NULL,
   [x] [int] NULL,
   [x] [datetime] NULL,
   [x] [int] NULL,
   [x] [datetime] NULL,
   [Sort] [int] NULL,
   [Storno] [bit] NULL,
   [x] [varchar](4) NULL,
   [x] [varchar](max) NULL,
   [x] [bit] NULL,
   [x] [varchar](20) NULL,
PRIMARY KEY CLUSTERED 
(
   [ID] ASC
)WITH (PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS  = ON, ALLOW_PAGE_LOCKS  = ON) ON [PRIMARY]
) ON [PRIMARY]
GO
SET ANSI_PADDING OFF
GO
/****** Object:  Default [DF_Storno]    Script Date: 03/14/2013 10:20:06 ******/
ALTER TABLE [dbo].[XXXX] ADD  CONSTRAINT [DF_Storno]  DEFAULT ((0)) FOR [Storno]
GO

[Furtbichler]

Also echt merkwürdig: Wenn ich die Tabelle erzeuge, eine ADOConnection und ein ADOTable drauflege und Daten eintrage und anschließend noch einmal ändere, funktioniert alles.

Erstell doch mal ein Beispielprojekt. Vielleicht liegt es gar nicht an ADO, sondern an irgendwelchen Seiteneffekten (aka Events).

[haentschman]

Danke...

Ich habe heute den ganzen Tag damit verbracht, dem ganzen auf die Spur zu kommen. Es sieht inzwischen so aus, das der Datensatz tatsächlich geändert bzw. gelockt ist. Ich habe mit dem Lock Mechanismus rumgespielt. Dabei habe ich auch UniDac ausprobiert. Wenn ich dem Mode auf Pessemistic stelle knallt es schon beim Edit. Das bedeutet im Umkehrschluß, daß der Datensatz geblockt ist. Leider kann ich trotz intensiven Debuggens die Stelle nicht finden wo ein Edit nicht abgeschlossen ist. Ein Lock None löst die Probleme. Wer zuletzt schreibt hat gewonnen. :roll:

...ob das aber so im Sinne des Erfinders ist ?

[Perlsau]

Zitat:

Zitat von haentschman (Beitrag 1207430)

...ob das aber so im Sinne des Erfinders ist ?

Immerhin wirst du auf diese Weise selbst zu ADO-Guru :-D