Insert in Zeos mit mehr als 24 Feldern

[Captnemo]

Tja, hat leider alles nicht genutzt. Weder das zur Laufzeit erzeugen des SQL-Strings mit Params.ParseSQL, als auch das austesten der verschiedenen LibmysqlXX.dll's. Immer der gleiche Fehler.

Der Fehler wird ja beim parsen des SQL-Strings erzeugt, und nicht an der Stelle im Source wo er sich auswirkt und der Debugger es meldet. Interessanterweise parst aber die OI zur Designtime richtig und ermittelt dann auch dir richtige Anzahl der Parameter. Wie Zeos das aber genau macht, weiß ich zu diesem Zeitpunkt noch nicht.

Ich werde jetzt noch einen weiteren Test machen, in dem ich eine neues Testprojekt anlege, in dem ich als einzige Fremdkomponente leditlich Zeos verwende, um evtl. inkompatibilitäten mit anderen Komponenten zu vermeiden.

Was ich mir nicht vorstellen kann ist, dass Zeos als auch D2010 diesbezüglich tatsächlich einen Fehler hat. Das ich hier einen Fehler mache, sehe ich aber leider auch nicht.

[mkinzler]

Du könntest deine Datenbankstruktur normalisieren :zwinker:

[Captnemo]

Zitat:

Zitat von mkinzler (Beitrag 1103863)

Du könntest deine Datenbankstruktur normalisieren :zwinker:

Was würde das an dem eigentlichen Problem ändern?

[Captnemo]

So, ich habe jetzt mit einem Testprojekt den "Fehler" gefunden. Auch wenn meiner Meinung nach trotzdem noch ein Fehler vorhanden ist.

Die Parameterübergabe als Value bei Feldern <> Varchar löst diesen Fehler aus.

Bei Feldern des Typ's varchar kann ich die Parameter als Value übergeben.
Bei Feldern des Typ's integer muß man asInteger und bei Feldern des Typ's Date muß man asDate verwenden. Dann funktioniert es auch mit mehr Felder. Ich habe in meinem Text 30 Testfelder erzeugt.
Ich gehe davon aus, dass die Zahl 24 lediglich an meiner Feldstruktur lag. Wenn ich Integer oder Date schon im 5. Feld verwendet hätte wäre es wohl schon nach 5 Feldern aufgetreten.

In früheren Zeos- und Delphi-Versionen habe ich immer alles außer Date, Time und Datetime als Value übergeben. Das ganze ohne Probleme. Warum das jetzt in dieser Version nicht funktioniert ist mir ein Rätsel.

[mkinzler]

Zitat:

Was würde das an dem eigentlichen Problem ändern?

Weniger Spalten in Tabelle(n) -> weniger benötigte Parameter

[blackfin]

Das wäre aber auch nur eine Notlösung, die das Problem nicht beseitigt, sondern evtl. nur auf einen späteren Zeitpunkt verschleppt.
Tabellen mit mehr als 24 Spalten sind in mySQL ja nicht wirklich eine Seltenheit oder etwas "abnormales" :zwinker:

[mkinzler]

Ist aber ein Zeichen auf einen niedrigen Normalisierungsgrad

[Captnemo]

Zitat:

Zitat von mkinzler (Beitrag 1103902)

Ist aber ein Zeichen auf einen niedrigen Normalisierungsgrad

Ich denke das hängt von der Art der zu speichernden Daten und deren Wiederverwendung ab. Grundsätzlich gebe ich dir Recht, möglichst wenig Tabellenspalten in den Tabellen zu haben erhöht auf jeden Fall die Übersichtlichkeit innerhalb einer Tabelle und auch deren Verarbeitungsgeschwindigkeit.
Allerdings halte ich nichts davon alles mögliche zu referenzieren nur um es halt zu tun, ohne das eine wirkliche logische Notwendigkeit dazu besteht. Des erhöht nicht nur die möglichen Fehlerquellen während der Entwicklung sondern auch zur Laufzeit (wenn z.B. während des Speichern oder Löschen von Daten das Clientprogramm den Vorgang nicht abschließen kann). Das kann evtl. im schlimmsten Fall zu Dateninkonsistenz führen.

Letztlich hängt vieles natürlich auch von den Kundenwünschen und der Art der Verwendung ab. In diesem Fall soll es nur ein Projekt für einen einzigen Kunden werden, und dessen Datenbestand wird auch nicht so wahnsinnig groß. Deswegen speichere ich alle Personenbezogenen Daten in einer Tabelle. Lediglich weitere Adressen werden ein einer zweiten Tabelle abgelegt.

Am Ende werde es 5 oder 6 Tabellen sein, auf die auch nur von 2-3 Arbeitsplätzen drauf zugegriffen wird.

Aber letztlich ging es mir ja darum, die Ursache für das Problem zu finden, was ich zum Teil ja gefunden habe (4 Beiträge weiter oben). Denn ein Problem zu umgehen heißt nicht dass es nicht mehr da ist. Und wie es im Leben immer so ist, kommt man immer irgendwann an den Punkt, wo es dann doch nicht umgehen kann.

Warum aber das bei mir nicht geht und D2010 und bei blackfin unter D2009 doch, kann ich nicht sagen. Wäre schön wenn wir das noch rausfinden, ist aber nicht zwingend notwendig. An dieser Stelle möchte ich mich auch bei allen bedanken. Durch eure Beiträge bin ich auf die richtige Spur gekommen und kann jetzt mein Projekt unter D2010 mit Zeos doch realisieren.

[mkinzler]

Code:

Des erhöht nicht nur die möglichen Fehlerquellen während der Entwicklung sondern auch zur Laufzeit (wenn z.B. während des Speichern oder Löschen von Daten das Clientprogramm den Vorgang nicht abschließen kann). Das kann evtl. im schlimmsten Fall zu Dateninkonsistenz führen.

Dafür gibt es Transaktionen. Zudem sollte die Fehlermöglichkeit/zu änderende/übertragende Datenmenge durch die Normalisierung sinken, da ja nur ein kleiner Teil übertragen/geändert wird.

Wenn du schon weitere Adressen in einer eigenen Tabelle speicherst, würde ich auch die "Hauptadresse" dort ablegen.

[Captnemo]

Zitat:

Zitat von mkinzler (Beitrag 1103930)

Dafür gibt es Transaktionen. Zudem sollte die Fehlermöglichkeit/zu änderende/übertragende Datenmenge durch die Normalisierung sinken, da ja nur ein kleiner Teil übertragen/geändert wird.

Wenn du schon weitere Adressen in einer eigenen Tabelle speicherst, würde ich auch die "Hauptadresse" dort ablegen.

Wie gesagt, grundsätzlich gebe ich dir schon recht.

War ja auch mit meinem DB-Design noch gar nicht fertig. Als ich die Tabelle angelegt hatte, war noch nicht klar, dass mehrere Adressen hinterlegt werden sollen. Das Projekt war grad erst 30 Minuten alt, als mich das Problem von allem anderen abgelenkt hat :-D