SQL Fehler, war zuvor nicht da, seid ??? vorhanden.

[Jens Hartmann]

Hallo zusammen,

es ist mal wieder klar, heute habe ich eine Vorführung meiner Software und irgendwie hat sich bei mir ein Fehler eingeschlichen, der bislang noch nicht da war.

Ich habe vor kurzem angefangen meine Software auf ein Datenmodul umzustellen, ob das damit zutun hat weiß ich zwar nicht, aber wenn ich jetzt über die alten Connection Kompo´s und Query´s, die auf meiner Form liegen was per SQL ändern will kommt immer folgender Fehler. (siehe Anhang)

Danke schon mal

Gruß Jens

[Nersgatt]

Und, hast Du kontrolliert, ob die Tabelle "MB256" existiert? Außerdem fällt auf, dass nach dem Tabellennamen noch ein Zeilenumbruch kommt und dann das ";". Sollte aber eigendlich nichts ausmachen. Ich denke, es fehlt halt die Tabelle.

Gruß,
Jens

[mkinzler]

Existiert die Tabelle in dedr Datenbank, auf die die Connection zugreift? Heisst diese genau so?

[Jens Hartmann]

Tabelle existiert. Ich habe auch an diesem Programmteil nichts geändert.

Beim INSERT, kommt z.B. folgender Fehler...

Gruß Jens

[Nersgatt]

Dort heißt die Tabelle auf einmal "MB256PLUS", vorher hieß sie "MB256". Ich denke, da fehlen wirklich ein paar Dinge in Deiner DB.

[GHorn]

Wenn ich das aus dem Screenshot richtig erkennen kann,
hast Du vor und nach den Klammern keine Leerzeichen.

INTO MB256PLUS(.....)Values(.....)


Im übrigen hat Nersgatt recht: Wieso die unterschiedlichen Tabellennamen?

Gruß
Gerald

[Jens Hartmann]

Hallo,

also einmal war das so. Die Tabelle heißt MB256PLUS. Allerdings kommt beim INSERT jetzt folgender Fehler.

Delphi-Quellcode:

  QryMB256PLUS.Close;
  QryMB256PLUS.SQL.Text := 'INSERT INTO MB256PLUS '+
      '(LFDNR, DATUM, UHRZEIT, EREIGNIS, TEILNEHMER, BEREICH) '+
      'VALUES (:LfdNr,:Datum,:Uhrzeit,:Ereignis,:Teilnehmer,:Bereich) ';

  QryMB256PLUS.ParamByName('LfdNr').AsInteger := ParserTreeViewMB256.EntriesMB256[0].LfdNr;
  QryMB256PLUS.ParamByName('Datum').AsString := ParserTreeViewMB256.EntriesMB256[0].Datum;
  QryMB256PLUS.ParamByName('Uhrzeit').AsString := ParserTreeViewMB256.EntriesMB256[0].Uhrzeit;
  QryMB256PLUS.ParamByName('Ereignis').AsString := ParserTreeViewMB256.EntriesMB256[0].Ereignis;
  QryMB256PLUS.ParamByName('Teilnehmer').AsString := ParserTreeViewMB256.EntriesMB256[0].Teilnehmer;
  QryMB256PLUS.ParamByName('Bereich').AsString := ParserTreeViewMB256.EntriesMB256[0].Bereich;

  QryMB256PLUS.ExecSQL;
  ConSecurdat.Commit;

Das mit den Klammern müsste doch eigendlich so stimmen

Gruß Jens

[mkinzler]

Kann es sein das manche Strings länger sind als das Feld? Oder nicht konvertierbare Werte vorliegen (Datum, Integer) usw?
Warum Datum als String in Tabelle?
BTW. .as<Typ>() ist überflüssig bei Typgleichheit

[Jens Hartmann]

DANKE, DANKE, ES Funktioniert.

Hatte einmal den falschen Tabellennamen und die falsche Query. Hatte an diesem Programmteil lange nichts geändert, aber die Datenbank angepasst.

Und zwar genau das mit dem Datum. Datum ist jetzt auch Date und nicht mehr String.

Daher der Convert Fehler.

Danke nochmal Gruß Jens

[Sherlock]

OT: Alter, mal im Ernst. Sowas darf eigentlich nicht passieren. Nach einer DB-Änderung solltest Du zumindest mal oberflächlich gucken, ob Dein Programm noch läuft...Regressionstest halt. Dann wüsstest Du auch genau, was Du geändert hast, und müsstest nicht diesen hier machen :gruebel:

Andererseits, dafür ist die DP ja da! :dp:

Ich freu mich für Dich, daß Deine Präsentation gerettet ist, und wünsch Dir viel Erfolg dabei :thumb:

Sherlock

[Jens Hartmann]

Zitat:

Zitat von Sherlock

OT: Alter, mal im Ernst. Sowas darf eigentlich nicht passieren.

Da hast du völlig recht. Problem, war das ich diese Hardwarekomponente nicht zur Verfügung hatte und somit nicht prüfen konnte. Dann kam heute morgen aber der Stress.

Aber, dafür gibt es ja die DP. Deshalb nochmal danke.

MFG

Jens

[hoika]

Hallo,

Zitat:

Problem, war das ich diese Hardwarekomponente nicht zur Verfügung hatte

Ausrede !!!! ;)

aber im Ernst.
Was hat denn eine Hardware-Komponente mit einem SQL-Zugriff zu tun ?

Keine ausreichenden Unit-Tests ?


Heiko

[Jens Hartmann]

Zitat:

Zitat von hoika

Ausrede !!!!

aber im Ernst.
Was hat denn eine Hardware-Komponente mit einem SQL-Zugriff zu tun ?

Da hast Du ja recht, die Hardwarekomponente hat damit nichts zu tun. Aber das Problem ist, das die Daten, die in diese Tabelle eingefügt werden, von dieser Hardware erzeugt werden und über die COM-Schnittstelle eingelesen werden.

Daher, konnt ich das ja ohne Hardware schlecht testen.

Um diesen Test durchzuführen, müsste ich also einen Datensatz habe, welchen ich dann über eine z.B. Testfunktion in die DB einlese. Da ich das aber bis jetzt ncoh nicht gemacht habe, kann ich momentan das eintragen in diese Tabelle nur mit Hardware testen.

Ich hoffe auf Verständis.


Gruß Jens

[himitsu]

Falls du noch länger mit dem Programm zu tun hast, dann erstell dir doch eine Weiche.

Also da wo auf den COM-Port zugegriffen wird, könntest du stattdessen auf eine Pipe oder eventuell auch eine Datei (wenn nur gelesen wird) umschalten und dir so, auch ohne Hardware, Testdaten ins Programm einscheußen.

Man könnte auch eine ganze Komponente gegen eine Dummy-Komponente austeuschen.
> z.B. die COM-Port-Komponente

[Jens Hartmann]

Danke,

da bin ich jetzt dran am überlegen. Ich denke das ich mit einer Textdatei zurecht kommen, die wie meine Datensatz aufgebaut ist. Allerdings überlege ich noch wie man das am Sinnvollsten realisieren kann. Mache ich mir da einen nicht sichbaren Button auf meine Anwendung, welcher dieses einlesen durchführt?

oder, vieleicht ein Label oder so...

Gruß Jens

[WoGe]

Zitat:

Zitat von himitsu

Also da wo auf den COM-Port zugegriffen wird, könntest du stattdessen auf eine Pipe oder eventuell auch eine Datei (wenn nur gelesen wird) umschalten und dir so, auch ohne Hardware, Testdaten ins Programm einscheußen.

Ich benutzte an solcher Stelle "echte Hardware". Ich simuliere Sensoren mit einem ATMega32. Das liegt daran dass die echte Hardware manchmal ein äußerst merkwürdiges zeitliches Verhalten hat, das mit lesen von Daten aus einem File kaum zu simulieren ist.
Wie könnte man sowas rein Softwaremässig simulieren?

@Jens: Genau deswegen ist die "Knopf-Methode" eher schlecht - außer es geht wirklich nur um die Datenbank.

Gruss
wo

[hoika]

Hallo,

der Fach-Begriff dafür heisst Mock-Objekt.

Wie das das umsetzt, hängt von deinen Wünschen ab.

Z.B. könnte man eine Boolean-Variable nehmen (bMock).

Ein Bsp. für einen DB-Zugriff, bei dem die DB auch nicht vorhanden ist
(ähnlich wie diene Hardware).

Delphi-Quellcode:

type
  TClass = class
    bMock: Boolean;
  end;

function CreateClass(bMock: Boolean = False): TClass;
var
  MyClass: TClass;
begin
  MyClass:= TClass.Create;
  MyClass.bMock:= bMock;
  Result:= MyClass;
end;


procedure TClass.ReadFromDB;
begin
  if not bMock then
  begin
   // normaler Zugriff
  end
  else
  begin
  // lese aus Textdatei
  end;
end;

Ja, ich weiss, dass ist nicht genau ein Mock-Objekt (das wäre ein eigenes Objekt),
aber man ist ja faul.

Beim Erzeugen der Klasse kann eine Boolean-Variable übergehen werden,
dann reagiert sie anders bei den internen methoden.

Auch Compilerschalter sind denkar.
{$DEFINE MOCK} {$IFDEF MOCK}

Mache ich aber nicht gern, weil man immer alles neu compilieren muss
bei einer Änderung.


Heiko