Insert in Zeos mit mehr als 24 Feldern

[Captnemo]

Hi Leute,

ich hab mir mal die ZEOSLIB_TESTING_REV878.zip runtergeladen und unter D2010 installiert. Die Installation war soweit kein Problem.
Nur kann ich kein Insert mit mehr als 24 Feldern durchführen. Compilieren läßt sich das Projekt ohne Probleme, aber wenn ich das Insert ausführe kommt immer eine
EZSQLException "Input parameter count is less then expected". Ich muß dazu sagen, dass ich das im Query mit Paramtern arbeite und diese dann mit Parambyname im Code
mit Werten fülle. War unter Zeos 6.6 und D7 nie ein Problem.

Folgendes Query funktioniert einwandfrei:

Code:

Insert into Kunden (Kundennummer, Anrede, Anrede2, Name, Vorname, Zusatz, Firma, TelefonG, FaxG, MobilG, EMailG, ZusatzG, TelefonP, FaxP, MobilP, EMailP, ZusatzP, Geburtstag, PANR, PAGueltig, FSNR, Strasse, PLZ, Ort) 
VALUES (:Kundennummer, :Anrede, :Anrede2, :Name, :Vorname, :Zusatz, :Firma, :TelefonG, :FaxG, :MobilG, :EMailG, :ZusatzG, :TelefonP, :FaxP, :MobilP, :EMailP, :ZusatzP, :Geburtstag, :PANR, :PAGueltig, :FSNR, :Strasse, :PLZ, :Ort)

Dieses liefert oben genannte Exception

Code:

Insert into Kunden (Kundennummer, Anrede, Anrede2, Name, Vorname, Zusatz, Firma, TelefonG, FaxG, MobilG, EMailG, ZusatzG, TelefonP, FaxP, MobilP, EMailP, ZusatzP, Geburtstag, PANR, PAGueltig, FSNR, Strasse, PLZ, Ort, REAnschrift) 
VALUES (:Kundennummer, :Anrede, :Anrede2, :Name, :Vorname, :Zusatz, :Firma, :TelefonG, :FaxG, :MobilG, :EMailG, :ZusatzG, :TelefonP, :FaxP, :MobilP, :EMailP, :ZusatzP, :Geburtstag, :PANR, :PAGueltig, :FSNR, :Strasse, :PLZ, :Ort, :REAnschrift)

Hat jemand eine Idee?

[Sir Rufo]

Hast du mal über den OI die Parameterliste kontrolliert? Sind da alle Parameter enthalten?

[mkinzler]

Zudem besteht da ein gewissen Spielraum für Normalisierung im Datenschema

[DelphiBandit]

Keine Idee, nur eine Vermutung. Könnte es sein, dass REAnschrift (Rechungsanschrift?) ein Blobfeld ist und es eher damit zu tun hat? Wenn ja, probier es mal mit einem "normalen" 25ten Feld aus.

Verwende Zeos dank IBDAC schon eine Weile nicht mehr, aber kann mir nicht vorstellen, dass die Entwickler gerade bei 24 Parametern Schluß machen.

[Coffeecoder]

Zitat:

Zitat von Sir Rufo (Beitrag 1102959)

Hast du mal über den OI die Parameterliste kontrolliert? Sind da alle Parameter enthalten?

Code:

EZSQLException "Input parameter count is less then expected"

Klingt fast nach einem fehlendem Parameter obwohl er eins mehr erwartet!?

[himitsu]

Wurden dann auch genügend/zuviele Werte via Parambyname hinzugefügt?

[Captnemo]

also:

- Im OI sind alle Parameter ebenfalls aufgeführt und richtig erkannt.
- Alle Parameter werden im Source mit Werten gefüllt
- REAdresse ist kein Blob sondern ein TinyInt-Feld
- Hab auch grad den Feldtyp auf Integer geändert, gleiche Fehler.

Ich kann mir das nicht erklähren. Ich arbeite schon seit Jahren mit Zeos und auf diese Weise. Nur bisher immer alle Projekte unter D7. Für die Portierung auf D2010 benötige ich aber auch dort Zeos. Nur wenn längere Insert's nicht gehen, dann könnte ich das nicht nutzen.

Hat jemand Zeos unter D2010 mit MySQL und kann (hat Lust ;-)) das mal test?

[haentschman]

Hallo
ändere mal das Feld Name in der DB und im SQL

[Captnemo]

Zitat:

Zitat von haentschman (Beitrag 1103031)

Hallo
ändere mal das Feld Name in der DB und im SQL

Hab ich gemacht, hat aber nichts gebracht.

Ich hab mal den Source angehängt, falls jemand möge hat, diesen mal auszuprobieren. Nicht dass ich irgendwie auf dem Schlauch stehe.

[blackfin]

Nur eine Vermutung: Es hat sich nicht zufällig irgendwo in einem Feld-Wert ein Single-Quote (') versteckt, der (unescaped) dann die SQL-Abfrage crasht?

Edit: wenn du noch ne DDL der mySQL-Tabelle anhängst, kann ichs mal ausprobieren, allerdings mit D2009

[galex9]

So wie es aussieht Fehler kommt aus ZDbcMySqlStatement.pas

Delphi-Quellcode:

function TZMySQLEmulatedPreparedStatement.PrepareSQLParam(ParamIndex: Integer): string;
...
  if InParamCount <= ParamIndex then
    raise EZSQLException.Create(SInvalidInputParameterCount);
...

Prüfe mal ParamIndex und InParamCount

[Captnemo]

Okay, hier ist ein Anhang mit der DB. Welche Zeos-Version benutzt du denn?

[blackfin]

Also..habs nun mal probiert, bei mir macht er das anstandslos ohne Fehler...
Allerdings habe ich D2009, das dürfte aber keinen grossen Unterschied diesbezüglich machen.
Ich habe nur bei mir die TAdvDatetimePicker rausgenommen und durch hartkodierte Datumseinträge ersetzt, da ich die Kompo nicht habe.

Zeos-Version: 7.0.0-dev (aus dem SVN, Revision 903 vom 19.05.2011)

Scheint also ein Bug in Zeos zu sein, der bereits gefixt wurde. Auch wenn man im Bugtracker und Changelog dazu nichts konkretes findet.

[Captnemo]

Zitat:

Zitat von galex9 (Beitrag 1103324)

So wie es aussieht Fehler kommt aus ZDbcMySqlStatement.pas

Delphi-Quellcode:

function TZMySQLEmulatedPreparedStatement.PrepareSQLParam(ParamIndex: Integer): string;
...
  if InParamCount <= ParamIndex then
    raise EZSQLException.Create(SInvalidInputParameterCount);
...

Prüfe mal ParamIndex und InParamCount

InParamCount scheint bei mir immer bei 24 festzustehen. Ich habe es mit 25 aber auch mit 23 Parametern im SQLString versucht. Immer ist InParamCount=24.

Sollte dieser Wert nicht die tatsächliche Anzahl der Parameter im SQLString wiedergeben?

[blackfin]

Probiers doch auch mal mit der aktuellsten Zeos-Version aus dem SVN:

svn://zeos.firmos.at/zeos/branches/testing

[Captnemo]

Zitat:

Zitat von blackfin (Beitrag 1103641)

Probiers doch auch mal mit der aktuellsten Zeos-Version aus dem SVN:

svn://zeos.firmos.at/zeos/branches/testing

Hab ich mir runtergeladen, alte Zeos deinstalliert, die aus dem svn installiert. Gleicher Fehler an gleicher Stelle. Kann mir das gar nicht erklären. So eine Sache wäre doch den Entwicklern von Zeos aufgefallen, denke ich.

[Satty67]

Zitat:

Zitat von Captnemo (Beitrag 1103807)

So eine Sache wäre doch den Entwicklern von Zeos aufgefallen, denke ich.

Denke auch... ;)

Würde den Code nochmal genau untersuchen, ob nicht doch irgenwo 24 Parameter gesetzt werden. Evtl. nochmal kurz vorm setzen alle Parameter löschen usw. Kann man sich irgendwie nicht vorstellen, das eine Begrenzung auf _nur_ 24 Parameter am Zeos Code liegt.

[Captnemo]

Zitat:

Zitat von Satty67 (Beitrag 1103809)

Würde den Code nochmal genau untersuchen, ob nicht doch irgenwo 24 Parameter gesetzt werden. Evtl. nochmal kurz vorm setzen alle Parameter löschen usw. Kann man sich irgendwie nicht vorstellen, das eine Begrenzung auf _nur_ 24 Parameter am Zeos Code liegt.

Tja, da gibt's leider nicht viel zu untersuchen. Im Code setzt ich lediglich per ParamByName, alle vorher über den OI im SQL-String des Query zur Designtime gesetzten Parameter. Und wenn ich eben auch nur auf 24 Parameter verkürze, dann klappt's ohne Probs. Und viel mehr Source gibt's in dem Projekt noch gar nicht.

Die Sache wäre nur blöd, weil ich jetzt für das Projekt jetzt wieder auf D7 zurück muß, und später dann dummerweise wieder portieren muß.

[haentschman]

* nach Strohlam greif *
...und wenn du den SQL String zur Laufzeit setzt ? vieleicht spinnt ja der OI ?

[blackfin]

Jetzt bin ich doch etwas verwundert, wieso geht dein Testprojekt dann bei mir mit der gleichen SVN-Zeos-Version und D2009?

Ich habe wie gesagt bei mir aufgrund der fehlenden Komponente nur die TAdvDatetimePicker durch hardgecodete daten ersetzt:

Delphi-Quellcode:

// statt
dm1.q_kunden_insert.ParamByName('Geburtstag').AsDate := dtp_geburtstag.Date;
//halt einfach
dm1.q_kunden_insert.ParamByName('Geburtstag').AsDate := StrToDate('31.12.1899');

Sonst keine Veränderungen am Code.
Auskommentiert habe ich auch nichts, es werden ja schon 25 Params in deinem Testcode übergeben.

Zum Testen habe ich in deinem Programm den Button "N" gedrückt (wohl "neuer Datensatz") und dann auf "S" (wohl "speichern" :-)).
Da gab es keinerlei Exceptions und die Daten waren auch danach in der DB (nachgeschaut mit phpMyAdmin).
Im zweiten Test habe ich vor dem Drücken von "S" noch in jedes Feld etwas reingeschreiben (auch ein evtl. "böses" single quote)
Auch dieser Datensatz war ohne Exception danach korrekt in der DB.

Als Test-Datenbank hatte ich eine mySQL 5.5 von ner Xampp-Version für Windows (XP).

Wo liegt jetzt noch der Unterschied?....ausser D2010...das habe ich zum Testen leider nicht.
Letzte Idee: deine libmysql50.dll ist möglicherweise eine zu alte / zu neue / falsche?
Wenn ich es richtig im Hinterkopf habe, gab es bei Zeos schon öfters mal merkwürdige Exceptions, wenn man die falsche dll verwendet hat.

Test 1:
Nimm erstmal die DLL aus deiner mySQL-Installation (liegt im /bin/-Ordner, musst du evtl. noch von libmysql.dll in libmysql50.dll oder libmysql55.dll umbenennen) und kopier diese in den Ordner deiner EXE. Dann starte das Projekt nativ ohne Debugger aus dem Ordner (damit er auch diese dll nimmt und nicht die, die die bds.exe / Delphi IDE zuerst gefunden hat).

Test 2:
Das gleiche wie oben, aber nimm testweise nacheinander die DLLs, die Zeos mitliefert (im lib/mysql/-Ordner), ausser die 4er DLLs.

[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