Probleme beim Speichern in eine Tabelle

[hoika]

Hallo,
ich werfe noch mal den DB-Monitor ins Spiel,
falls es für diese Zugriffskomponenten einen gibt.


Hattest Du das eigentlich auch mal schrittweise debuggt?


#41

[Frickler]

Zitat:

Zitat von Uwe Raabe (Beitrag 1410166)

Zitat:

Zitat von hoika (Beitrag 1410164)

Hallo,
wenn ich ein VarChar-Feld vergrößere, ändert sich die Feldlänge auch in dem persistenten Feld?

Wenn in FieldOptions.UpdatePersistent auf true steht, ja.

Oder indem man die persistenten Felder einfach zur Laufzeit erzeugt. Das funktioniert dann bei jeder Delphi Version, nicht bloß bei den neusten.

[Luckner]

Delphi-Quellcode:

create table planung
(
  kundennr varchar(20),
  artikelnr varchar(10),
  bestellnr varchar(20),
  bestelldatum date,
  bestellmenge integer,
  lieferdatum date,
  liefermenge integer,
  format varchar(10),
  produktionsnr integer,
  maschine varchar(20) collate de_de,
  produktionsstunden decimal(7,2),
  id integer,
  lager integer,
  id_artikel integer,
  lageranzahl integer,
  lagerproduktion smallint,
  statusdatum date,
  statusname varchar(10) collate de_de,
  status varchar(30) collate de_de,
  id_auftrag integer,
  artnrsuffix smallint,
  auflage integer,
  bemerkung varchar(200) collate de_de,
  eingangsdatum date,
  rohwarenr integer,
  geliefert smallint,
  krawartnr varchar(15)
);

grant delete, insert, references, select, update
 on plannung to  sysdba with grant option;

Delphi-Quellcode:

create table auftrag
(
  id integer not null,
  kundennr varchar(20),
  artikelnr varchar(10),
  bestellnr varchar(20),
  bestelldatum date,
  bestellmenge integer,
  lieferdatum date,
  krawartnr varchar(15),
  krawauftrnr varchar(15),
  liefermenge integer,
  format varchar(10),
  gruppe integer,
  obermaterial varchar(30),
  kleber varchar(30),
  traeger varchar(30),
  farbe1 varchar(20),
  farbe2 varchar(30),
  farbe3 varchar(30),
  farbe4 varchar(30),
  lepoanzahl1 integer,
  lepoanzahl2 integer,
  lepoanzahl3 integer,
  lepoanzahl4 integer,
  anzahlaufrolle integer,
  grundpreis decimal(10,2),
  lochrand varchar(5),
  blattanzahl1 integer,
  blattanzahl2 integer,
  blattanzahl3 integer,
  blattanzahl4 integer,
  blattanzahl5 integer,
  blattanzahl6 integer,
  drucktext blob sub_type 0,
  bemerkung blob sub_type 0,
  zuschlag1 decimal(10,2),
  zuschlag2 decimal(10,2),
  zuschlag3 decimal(10,2),
  zuschlag4 decimal(10,2),
  zuschlag5 decimal(10,2),
  zuschlag6 decimal(10,2),
  zuschlag8 decimal(10,2),
  zuschlag7 decimal(10,2),
  zuschlag9 decimal(10,2),
  zuschlag10 decimal(10,2),
  zuschlag11 decimal(10,2),
  zuschlag12 decimal(10,2),
  zuschlag13 decimal(10,2),
  wiwa decimal(10,2),
  rechnnr varchar(10),
  positionssumme decimal(10,2),
  bild varchar(100),
  vkpreis decimal(10,2),
  rekladatum date,
  reklamenge integer,
  rechnnr2 varchar(10),
  produktionsnr integer,
  maschine varchar(20) collate de_de,
  id_artikel integer,
  planliefertermin date,
  produktion integer,
  lagerort varchar(10) collate de_de,
  lagerproduktion smallint,
  datum date,
  anwender varchar(10) collate de_de,
  statusdatum date,
  statusanwender varchar(10) collate de_de,
  prodstatus varchar(30) collate de_de,
  artnrsuffix smallint,
  individuallager integer,
  text varchar(100) collate de_de,
  druckdatei varchar(100) collate de_de,
  form varchar(50) collate de_de,
  auflage integer,
  produktionsbemerkung blob sub_type 0,
  originalbild varchar(100) collate de_de,
  eingangsdatum date,
  rohwarenr integer,
  rohwareausloesen smallint
);

grant delete, insert, references, select, update
 on auftrag to  sysdba with grant option;

Die *.dfm lässt sich irgenwie nicht hochladen.
Ich versuche es mit anderem Browser.

[Luckner]

Komisch ist, dass ich auf diese Tabellen mit einem anderem von mir erstelltem Programm zugreife und da funktioniert es ohne Probleme. Kann sein, dass ich langsam den Wald vor lauter Bäume nicht sehe.

[hoika]

Hallo,
zip-Datei nehmen.

[Luckner]

Jetzt gezipt.

[hoika]

Hallo,
http://docwiki.embarcadero.com/Libra...ase.TraceFlags

Es gibt von Embarc. einen SQL-Monitor.
Dann kannst Du Dir schon mal die SQL-Statements ansehen, die durchs Land huschen.

[Frickler]

Werden die beiden Tabellen im Formular einfach nur geöffnet, editiert, gespeichert, geschlossen, oder hat das Formular auch zusätzlich noch datensensitive Steuerelemente (TDBEDit & Co), in denen die Feldwerte zusätzlich angezeigt werden?

[Luckner]

Zur Frickler,
diese Tabellen werden einfach nur geöffnet, editiert und geschlossen.

[Uwe Raabe]

Keine Ahnung, ob das relevant ist: In den SQL-Statements von IBDataSetPlanung wird der Tabellenname als PLANNUNG anstatt PLANUNG angegeben.

[Uwe Raabe]

Du könntest nach dem Post auch mal den Wert von RowsAffected überprüfen.

[Luckner]

Ist nicht relevant. Habe diese Tabelle vor ca. 4 Jahren angelegt und wohl mit nn. Als ich den Fehler gemerkt hatte, waren schon einige Datensätze drin. Hatte keine Zeit und Lust den Namen zu ändern. Beim Anwender fällt es nicht auf.

[Uwe Raabe]

Zitat:

Zitat von Luckner (Beitrag 1410239)

Ist nicht relevant. Habe diese Tabelle vor ca. 4 Jahren angelegt und wohl mit nn. Als ich den Fehler gemerkt hatte, waren schon einige Datensätze drin. Hatte keine Zeit und Lust den Namen zu ändern. Beim Anwender fällt es nicht auf.

Aber der Code, den du hier bisher gezeigt hast (insbesondere der im ersten Post), verwendet nur ein N. Es führt halt immer zu Verwirrung, wenn der gezeigte Code nicht der ist, der tatsächlich ausgeführt wird.

[Frickler]

Zitat:

Zitat von Luckner (Beitrag 1410236)

Zur Frickler,
diese Tabellen werden einfach nur geöffnet, editiert und geschlossen.

Und es gibt keine Fehlermeldung, selbst wenn Du in den SQL-Text der 2. Abfrage irgendwelche Fehler einbaust, wie Hoika in #13 verschlug? So a la

Code:

select * FROM PLANUNG where bla = blubb and ID_AUFTRAG = ' + IntToStr(id_Planung)

Wobei: wenns eigentlich "Plannung" heißt, hat die Anweisung ja schon einen Fehler...

Wie ist denn das Fehlermanagement in dieser Routine? Was steht im EXCEPT teil?

[Luckner]

Das stimmt. Wollte diesen Fehler hier nicht so raushängen. An welcher Stelle wird RowsAffected eingesetzt? Hatte es jetzt nach IBTransactionPlanung.Commit eingesetz und da bekomme ich ein 0.

[Luckner]

Hallo Frickler,
im Original steht PLANNUNG. (Peinlich)

[Delphi.Narium]

Im dfm greift so ziemlich alles, was mit der Tabelle PLANUNG zu tuen haben soll auf die Tabelle PLANUNGSPEZIAL zu, auch die persistenten Felder.

Irgendwas passt da nicht:

Open, Edit und Post gehen (laut SQL) auf die Tabelle PLANUNG, die Felder aber auf PLANUNGSPEZIAL.

Verwunderlich, dass es da nicht dauernd kracht.

Achne, es gibt ja auch noch das DataSet GridPlanung, das geht auf PLANUNGSPEZIAL.

Irgendwie verstehe ich momentan nur noch Bahnhof.

[Uwe Raabe]

Zitat:

Zitat von Luckner (Beitrag 1410242)

An welcher Stelle wird RowsAffected eingesetzt?

Im Post. Wenn danach eine 0 drin steht, war kein Datensatz von der UPDATE-Query betroffen. Das deckt sich auch mit deiner Beobachtung in Flame Robin.

Zitat:

Zitat von Delphi.Narium (Beitrag 1410244)

Im dfm greift so ziemlich alles, was mit der Tabelle PLANUNG zu tuen haben soll auf die Tabelle PLANUNGSPEZIAL zu, auch die persistenten Felder.

Das ist ein anderes DataSet: IBDataSetGridPlanung

[Luckner]

Habe RowsAffected jetzt auf die IBDataSetAuftrag eingesetzt(hier wurde der Eintrag auch korrekt eingetragen) und der Wert ist 1. Was auch so richtig ist. Hatte es jetzt nach IBTransactionPlanung.Commit eingesetzt. Also schaue ich mir noch einmal die select-Routine an.

[Luckner]

In der Tabelle PLANUNGSPEZIAL werden Daten aus den Tabellen "PLANNUNG, AUFTRAG, ROHWARE" gesammelt und über ein IBDatasetGrid in einem Grid angezeigt. In PLANUNGSPEZIAL wird Nichts gespeichert.

[Luckner]

Keine Ahnung Was nicht funktioniert. Select-String ist richtig. Kurz bevor ich poste gebe ich mir einen Wert aus dem Datensatz aus und der ist auch korrekt. Post macht er und hinterher bekomme ich RowsAffected = 0. Diese RowsAffected ist schon ein tolles Teil. Kannte ich nicht.

[Uwe Raabe]

Wenn RoswAffected 0 liefert, dann wurde zu der WHERE Bedingung im ModifySQL kein Eintrag gefunden. Lass dir doch vor dem Post das Feld ID des Datensatzes anzeigen, denn die ist für das UPDATE relevant.

[himitsu]

Zitat:

Zitat von Uwe Raabe (Beitrag 1410138)

Zitat:

Zitat von Luckner (Beitrag 1410137)

Es gibt auch keinen Datensatz in der Tabelle "Planung", der diesen Eintrag trägt.

Sollte es in dem Fall dann nicht

Delphi-Quellcode:

DatamodulePlanung.IBDataSetPlanung.Append;

anstatt

Delphi-Quellcode:

DatamodulePlanung.IBDataSetPlanung.Edit;

heißen?

Edit macht ein Insert (oder Append, aber egal, da hier das Gleiche) wenn noch "garkein" Datensatz vorhanden ist,

aber ja ...

[Luckner]

Danke erstmal für die Hilfe. Mache jetzt Feierabend und werde mich morgen wieder damit befassen. Muss unbedingt duschen.

Gruß, Luckner

[Frickler]

Zitat:

Zitat von himitsu (Beitrag 1410251)

Edit macht ein Insert (oder Append, aber egal, da hier das Gleiche) wenn noch "garkein" Datensatz vorhanden ist,

Andererseits schrieb der TE, dass nach dem Select "RecordCount" 1 ergibt. Wobei ich nicht weiß, ob das auch 1 ergibt, wenn die Selektion nichts ergibt und Edit einen Datensatz anhängt.

Die ganze Geschichte ist eh total fehlerträchtig. Warum nicht direkt (für Dialect 1) ein

Code:

UPDATE AUFTRAG
SET STATUS = :ST, STATUSDATUM = CURRENT_TIMESTAMP, STATUS_ANWENDER = :ANW
WHERE ID = :ID

und

Code:

UPDATE PLANNUNG
SET STATUS = :ST, STATUSDATUM = CURRENT_TIMESTAMP, STATUS_ANWENDER = :ANW
WHERE ID_AUFTRAG = :IA

Das ganze in eine Procedure wrappen mit den zu updatenden Werten als Parameter und gut ist. Wenn beide Wertänderungen zusammengehören kann man die gleich in einer gemeinsamen Transaktion abfrühstücken.

Oder geht das nicht mit den verwendeten Komponenten?

[p80286]

Du bist doch nicht mehr...........
Über eine Query zwei Statements absetzen und wissen was passiert(ren sollte) und sich damit 63 Threadeinträge sparen. Unverantwortlich!


Gruß
K-H

[Luckner]

Hallo,
gerade eben habe ich das Problem gelöst und es funktioniert. In der Tabelle Plannung:oops: existierte zwar das Feld "ID", aber alle Datensätze in diesem Feld war auf "nil". Diese Tabelle wird mehrmals am Tag aus mehreren anderen Tabellen erstellt und das Feld "ID" wird nicht gebraucht. Mit dem RoswAffected und dem Hinweis auf ModifySQL (danke Uwe Raabe) habe ich das Schlüsselfeld ID =: OLD_ID gegen ID-AUFTRAG =: OLD_ID_AUFTRAG geändert. und es funktioniert. Habe jetzt vorsorglich "ID" aus dieser Tabelle gelöscht.
Vielen Dank, Luckner

[p80286]

Zitat:

Zitat von Luckner (Beitrag 1410495)

und das Feld "ID" wird nicht gebraucht.

Also ist es unmöglich (nicht unwahrscheinlich!) das es Datensätze mit unterschiedlichen Inhalten gibt!?

(übrigens gibt es für viele Datenbanken die Möglichkeit die ID (Schlüssel) automatisch erzeugen zu lassen. Und mit ID ist jeder Datensatz individuell definiert und Zugriffe sind u.U schneller (Index))

Gruß
K-H

[hoika]

Puh,
Thread ist erledigt...