Programm friert ein beim Ändern von DBGrid Einträgen

[Bambuti2000]

Hallo Leut's,

ich kämpfe inzwischen schon seit zwei Tagen an einem Problem.
Ich hab ein einfaches Formular mit einem DBGrid. Dazu kommen zwei ADOQuery und eine DataSource.
Mit der ersten Query rufe ich alle Tabellen-Name in einer DB2-DB zur manuellen Auswahl ab.
Mit der zwieten Query Rufe ich dann bei Auswahl die jeweiligen Daten ab und zeige diese in der DBGrid an. Soweit, so gut.
Bearbeite ich allerdings nun einen der angezeigten Datensätze direkt im DBGrid, firert beim (autom.) posten, also Zeilenwechsel die Aplikation ein.
Ich habe schon diverse Versuche gestartet und das halbe Internet durchforstet aber leider keine Lösung gefunden.
Wenn ich mir zusätzlich Infos bei den Ereignissen der Query ausgebe, ist das letzte was passiert "OnWillChangeRecord", dann ist's aus...
Die Datenbank rufe ich mit einer einfachen "SELECT-Anweisung" ohne WHERE-Klausel ab.

Vielen Dank für eure Hilfe...

Gruß
Stefan

[Bambuti2000]

OK, bevor ich mit Antworten überschüttet werde,

hier noch ein paar neue Info's resultierend aus wieteren Tests...

Gleiches Konstrukt, allerdings diesmal verbunden mit einer MSSQL.
Alles funktioniert so wie es sein soll (update Datensatz, neuer Datensatz, löschen).

Also, gibt es wohl Probleme bei ADO => DB2.
An der DB kanns übrigens nicht liegen, hab mal testweise mit 'ner Access-MDB drauf zugegriffen, funktioniert auch alles.

Deshalb, wer eine Ahnung haben könnte warum ich mit der DB2 Probleme habe, melde dich bitte ...

Gruß
Stefan

[jobo]

Was nimmst Du denn nun zum Zugriff?
ADO(OLEDB)
oder
ODBC
oder
ADO(OLEDB)>ODBC

?

[Bambuti2000]

Sorry dass ich so lange nichts von mir hören lassen habe.
Hatte in letzter Zeit 'ne ganze Menge Arbeit mit 'nem riesigen Projekt bei uns.

Die Datenbank "connecte" ich via ODBC. Ich hab das Problem auch inzwischen einschränken/weiter analysieren können.
Es liegt wohl daran dass die DB2 Tabellen keinen Primärschlüssel haben.
Da sind wir aber ja direkt wieder am Thema, wie kann ich über DBGrid nun in dieser Tabelle INSERTS/UPDATES/DELETES nutzen? So ganz ohne Primärschlüssel?

[himitsu]

Es kommt auf die DB-Zugriffskomponenten drauf an.
Bei Einigen kann man selber passende Update/Insert/Delete-Statements angeben, welche etwas Anderes zur Identifizierung nutzen. (wenn nicht, dann wird intern über den Primärschlüssel automatisch etwas generiert)

z.B. PgDAC kann's, also vermutlich auch UniDAC, AnyDAC und Co.


Oder du erstellst einen Primärschlüssel?

[Bambuti2000]

OK,
Primärschlüssel erstellen kann ich total vergessen. Die Datenbanke (einige 100) werden von den DBA's administriert. DB2 verlngt grundsätzlich keinen und kann so wohl auch sehr gut und vorallem schnell arbeiten.
Ich persönlich arbeite mit einigen MS- und MySQL DBs und habe es gelernt, immer einen Primärschlüssel anzulegen. Somit habe ich bisher auch keine Probleme gehabt. Wenn das dann mit ADO so nicht klappt, dann werde ich wohl mal eine andere Komponente probieren.
Danke für die Hilfe.

[mkinzler]

Zitat:

Primärschlüssel erstellen kann ich total vergessen. Die Datenbanke (einige 100) werden von den DBA's administriert

.
Was sind das für DBA's? Ohne Wissen über relationale Datenbanken.

Zitat:

DB2 verlngt grundsätzlich keinen und kann so wohl auch sehr gut und vorallem schnell arbeiten.

Verlangt werden diese von keinem DBMS. Wer aber ein klein wenig von Datenbanken versteht, verwendet diese.

[Sir Rufo]

Zitat von mkinzler:

Zitat:

Primärschlüssel erstellen kann ich total vergessen. Die Datenbanke (einige 100) werden von den DBA's administriert

.
Was sind das für DBA's? Ohne Wissen über relationale Datenbanken.

Vermutlich handelt es sich um eine DB2 auf einer AS/400 und da ticken die Uhren noch etwas anders, bzw. es gibt dort neben reinem SQL auch noch andere Zugriffsarten auf die Daten und die werden von diesen Jungs bevorzugt genutzt