Fehler: Dynamic SQL Error, SQL error code = -842, Positive..

bash · Beiträge: 21

Hallo,

ich bekomme immer eine Fehlermeldung, wenn ich mit IBTable eine neue Tabelle erstellen möchte.
Der Fehler lautet::
Dynamic SQL Error, SQL error code = -842, Positive value expected!

Und hier noch der Quelltext dazu:

markieren

Quelltext

1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
18:
19:
20:
21:
22:
23:
24:
25:
26:
27:
28:
29:
30:

tb_Adressen.TableName := 't_adressen';

        with tb_Adressen.FieldDefs do begin
            Clear;
            Add('ID', ftInteger);
            Add('Name', ftString, 20, TRUE);
            Add('Vorname', ftString, 20, TRUE);
            Add('Strasse', ftString, 30);
            Add('PLZ', ftString, 10);
            Add('Ort', ftString, 30);
            Add('Land', ftString, 20);
            Add('Geburtstag', ftDate);
            Add('Kanal1', ftInteger);
            Add('Kanal2', ftInteger);
            Add('Verein', ftString, 30);
            Add('EMail', ftString, 20);
            Add('Homepage', ftString, 40);
            Add('Telefon', ftString);
        end;

        with tb_Adressen.IndexDefs do begin
            Clear;
            Add('ix_ID', 'ID', [ixPrimary,ixUnique]);
        end;

        ta_Adressen.StartTransaction;
        tb_Adressen.CreateTable;
        ta_Adressen.Commit;

        tb_Adressen.Close;

Wäre dankbar für jeden Hinweis!
Bis dann

bis11 · Beiträge: 1247 Erhaltene Danke: 2 Apple Mac OSX 10.11

Aber wenn ich mich nicht Irre, muß ich für einen String immer eine Länge angeben oder ? Wenn ja, dann schau Dir mal Deine Zeile an, wo Du das Feld Telefon erstellst.

LCS · Verfasst: Do 12.09.02 08:38

Hi
wenn du eine IB Datenbank verwendest, ist es wesentlich einfacher und effizienter wenn du deine Tabelle ebenfalls mit SQL erstellst. Zum Beispiel mit dieser Anweisung:

markieren

Quelltext

1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:

CREATE TABLE t_adressen (
  ID  integer not null,
  Name  varchar(20),  /* Name solltest du nicht verwenden */
  Vorname  varchar(20),
  Strasse  varchar(30),
  Plz  varchar(10),
  Ort  varchar(30),
  Land  varchar(20),
  Geburtstag  Date,
  Kanal1  integer,
  Kanal2  integer,
  Verein  varchar(30),
  EMail  varchar(20),
  Homepage  varchar(40),
  Telefon  varchar(20),
  primary key (ID));

Verwende dazu einfach eine IBSQL Komponente, Eigenschaft SQL mit dieser Anweisung füllen und ExecQuery ausführen.
Auf TIBTable solltest du überhaupt nach Möglichkeit ganz verzichten.

Gruss Lothar

_________________
Der BH ist für die Brust, der Plan ist für'n Ar...

hansa · Beiträge: 3079 Erhaltene Danke: 9

Hi,

habe meine Dateien auch mit isql erstellt, aber eigentlich nur, weil ich zu faul war zu lesen wie das mit Delphi geht (wegen Fehlern wie diesem). Mit isql hatte ich sie ja sowieso schon.

Im Prinzip hatte ich aber auch vor, das mit Delphi zu machen. Wenn ich früh genug wisse, warum das effizienter ist kann ich mir das ja sparen.

Also: was spricht dagegen ?

Gruß
Hansa

thePraYeR · Beiträge: 27

Gegen die Erstellung von Objekten mit Delphi spricht vor allem, daß eine ganze Reihe Zusatzarbeit, die auch noch notwendig ist, von hinten durch die Brust ins Auge gemacht werden muß.

Weil:
Wenn neue Tabelle, dann sollte man einen Primärindex hinzufügen. Für einen Primärindex benötigen wir:
- einen Generator

markieren

Quelltext

1:	CREATE GENERATOR <NAME>;

- einen Trigger, der eindeutige ID zuweist

markieren

Quelltext

1:
2:
3:
4:
5:
6:
7:
8:

SET TERM 

CREATE TRIGGER <name> FOR <tabelle> BEFORE INSERT AS  
BEGIN
  NEW.ID = GEN_ID(<generatorname>,1);
END

SET TERM ;

- einen Trigger, der Änderungen an den ID verhindert

markieren

Quelltext

1:
2:
3:
4:
5:
6:
7:
8:

SET TERM 

CREATE TRIGGER <name> FOR <tabelle> BEFORE UPDATE AS  
BEGIN
  NEW.ID = OLD.ID;
END

SET TERM ;

- und Zuweisung von Berechtigungen

markieren

Quelltext

1:

GRANT ...

Also: Lieber alles in's IBSQL-Objekt rein (alles zusammen) und Feuer geben.

hansa · Beiträge: 3079 Erhaltene Danke: 9

Hallo thePraYeR,

endlich mal ein Name, den man nicht mehr von Hand schreiben kann.

Jetzt im Ernst : Habe hier eine DB mit einem Trigger (Before Insert).

Das Programm läuft auch ohne den zweiten. Ich verstehe nicht so ganz, warum ich den überhaupt brauche ? Er macht doch eigentlich nur Sinn, wenn ich zulasse die ID's von Hand einzutragen.

Oder habe ich zu wenig getestet?

Gruß
Hansa

LCS · Verfasst: Sa 14.09.02 18:55

Hi hansa
natürlich läuft's auch ohne den zweiten Trigger. Wenn du die ID nur intern verwendest und nirgendwo anzeigst, kannst du dir den sparen.
Wenn sie aber sichbar ist, könnte der Anwender ja auf die Idee kommen sie zu ändern. Und der einfachste Weg das (und den resultierenden Ärger) zu verhindern ist der von thePraYeR (Arghh!!) beschriebene Trigger.

Gruss Lothar

_________________
Der BH ist für die Brust, der Plan ist für'n Ar...

thePraYeR · Beiträge: 27

Der zweite Trigger mach Sinn, weil er unbeabsichtigte Änderungen an den ID verhindert. Ist zwar auch über die Zuweisung von externen Referenzen möglich, aber zum einen gibts die nicht in jeder Tabelle und zum zweiten produziert das hier keinen SQL-Fehler, wenn sich jemand unbedarftes mit SQL auf die Tabelle setzt (über Access z.B.).

Das Problem ist i.d.R. nicht das Programm, sondern die Möglichkeit, ohne das Programm auf die DB zuzugreifen. Ich habe die Erfahrung gemacht, daß Berechtigungen an sich kaum eine Möglichkeit sind, spleenige Ideen von irgendwem zu verhindern (daß z.B. alle Indizes neu erstellt werden müssen, weil Lücken drin sind), Trigger jedoch schon. Weil da i.d.R. nochmal genauer drüber nachgedacht wird, was überhaupt erreicht werden soll.

hansa · Beiträge: 3079 Erhaltene Danke: 9

Hallo thePraYeR,

aha, so ungefähr hab ichs mir gedacht.

Gruß
Hansa

	Mitgliederliste
	Gruppen
	Das Team
	Richtlinien
	Synonyme