ADO Guru gesucht

[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