Firebird Embedded + AUTOINC

[jobo]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1287055)

Macht der MS SQL Server genauso.
Mit dem "Vorteil" das bei Änderungen der zugrundeliegenden Datenbank der View ermals mit nicht nachvollziehbarer Fehlern abbricht - jedenfalls gabs das Problem mit älteren Versionen des Servers. Musste man dan händisch neu compilieren lassen.

Automatische Recompilierung schafft Oracle leider auch nicht immer.
Aber immer öfter.

[p80286]

Zitat:

Zitat von jobo (Beitrag 1287060)

Automatische Recompilierung schafft Oracle leider auch nicht immer.
Aber immer öfter.

Jojo...

Zitat:

Zitat von Perlsau (Beitrag 1287038)

Nicht einfacher und dann doch einfacher :?:

Da hast Du die zeitliche Abfolge vernachlässigt. Erst hat man den Aufwand, jeden ... zu berücksichtigen und danach geht's rubbel die Katz!

Und bitte nicht vergessen, es gibt Datenbanken, da kommt man als Benutzer nur an die Views heran.

Gruß
K-H

[mikhal]

Das Problem der neu zu compilierenden Views gibt es bei Oracle auch, wenn die Definitionen der zugrundeliegenden Tabellen geändert werden, das zieht sich aber durch über procedures und functions, Jobs, Trigger etc. Liegt wohl in der Natur der Sache.

Dass es Datenbanken gibt, bei denen der Benutzer nur die Views zu sehen bekommt, liegt wohl eher daran, dass der Benutzer ausschließlich die Rechte erhalten hat, Views zu verwenden. In Data Ware House Datenbanken war und ist das üblich, damit die Daten nicht verändert werden können.

Grüße
Mikhal

[Dejan Vu]

Probleme mit Views kenne ich bei einer View, die '*' verwendet, wobei die verwendete Tabelle in der Struktur erweitert/verändert wird.

Code:

CREATE VIEW View_WillBlowUp as
select * from Foobar

Ein Wort noch zu Views: Wer wiederverwendbaren Code schreibt, oder Clean-Code anwendet (also Codeteile durch Einbetten in eine kleine Methode dokumentiert), sollte auch Views, UDF und SP verwenden. Damit wird der SQL-Code einfach lesbarer. Wer Obfuscation liebt, der verwendet die natürlich nicht, ist ja klar.

Und wenn sich einmal die Definition der 'OpenInvoices' ändern sollte (bitte keine internen Rechnungen an die IT), dann macht man das an einer einzigen Stelle: Nämlich in der View. Und ab *sofort* sind alle Reports, Auswertungen und Programme angepasst und zeigen stringent die gleiche Information.

Allerdings ist die Verwendung einer View in extrem komplexen Queries (also wenn die Query selbst mit Views arbeitet) nicht immer schneller. Leider. Da muss man die View dann materialisieren und mit einem Index versehen, oder zu anderen Tricks greifen.

[ATS3788]

Ich habe da noch eine Frage, aber davor Danke Perlsau so ist das ja echt :thumb:

Muss ich in Firedac noch was eistellen mein counter zählt nicht

der ist bis jetzt ein einfaches

FDTable1COUNTER: TLargeintField;

was übersehe ich ?

[Hansa]

Erstelle einen Datenbank-Trigger und fertig.

[ATS3788]

Danke
Nur wenn ich das in der Datenbank mit IBExpert mache,
geht das, mit Firedac nicht. OK mal sehen.:pale:

Before is Active


as
begin
if (new.counter is null) then
new.counter = gen_id(gencounter,1);
end

[ATS3788]

Das

Delphi-Quellcode:

   FDTable1COUNTER.AutoGenerateValue := arAutoInc;

:-D

muss man initialisieren, dann geht es.

War unter den vielen Infos, nicht leicht zu finden,

http://docwiki.embarcadero.com/Libra...eneratorsPoint

gehört meiner Meinung als Info auf folgende Seite

http://docwiki.embarcadero.com/RADSt...elder_(FireDAC)

[Hansa]

Das kann so fast nicht sein. FireDAC müsste dann irgendwie den Trigger in der Datenbank aushebeln. Wie das ? :shock: Und warum ? Sorry, aber meine Phantasie reicht da nicht aus.

[TBx]

Wozu sollte Firedac den Trigger aushebeln müssen? Firedac übergibt einfach den Wert für das Feld und das wars.

[Hansa]

Aber wenn in der DB doch ein Trigger definiert ist und der auch mit IBExpert zuschlägt, wieso soll es dann nötig sein für FireDAC noch irgendwas einstellen zu müsssen ? Au mann, immer alles ausführlich schreiben, obwohl eigentlich einleuchtend. In IBExpert schlägt also der Trigger zu. Ist ja auch klar, weil der in der Datenbank angelegt wurde. Angeblich ist das im Delphi-Programm aber nicht so (zumindest von mir auch nicht nachvollziehbar). Wenn dem aber doch so ist (ich glaubs nicht), dann bestünde theoretisch die Möglichkeit, dass FireDAC den Trigger auf Inactive setzt, was ich auch nicht glaube aber theoretisch ginge das. Und das wäre dann die einzige Möglichkeit, diesen Effekt zu erzeugen. Der Trigger schlägt immer zu ! Ohne wenn und aber. Und der gepostete Trigger sieht richtig aus und soll unter IBExpert auch funktionieren !

[TBx]

Zitat:

Zitat von Hansa (Beitrag 1318274)

In IBExpert schlägt also der Trigger zu. Ist ja auch klar, weil der in der Datenbank angelegt wurde. Angeblich ist das im Delphi-Programm aber nicht so (zumindest von mir auch nicht nachvollziehbar).

Steht doch klar und deutlich im Trigger:

Zitat:

Zitat von ATS3788 (Beitrag 1318257)

as
begin
if (new.counter is null) then
new.counter = gen_id(gencounter,1);
end

Der setzt genau dann und nur dann den Wert, wenn das Feld null ist.
Es hängt also davon ab, was Firedac als Standard für ein nicht belegtes integer-Feld übergibt.

[Hansa]

Dies würde bedeuten, wenn man folgendes macht :

Delphi-Quellcode:

   FDTable1COUNTER.AutoGenerateValue := arAutoInc;

dann wird automatisch die NULL überschrieben ? Mit was denn ? Woher soll denn FireDAC wissen auf welchem Wert die ID einer einzelnen Tabelle steht ? Ich hantiere hier z.B. gerade mit ca. 50 Tabelllen, die sich die ID aus einem einzigen Generator holen. Wozu also arAutoInc; setzen ? @TBx : erklär mir das mal und auch, wie man so (intern in FireDAC) die richtige ID finden soll.

[jobo]

Zitat:

Zitat von Hansa (Beitrag 1318280)

Dies würde bedeuten, ..
dann wird automatisch die NULL überschrieben ? Mit was denn ?

Der Trigger ist so geschrieben, dass er nur selbst einen Wert vergibt, wenn das Feld noch NULL ist. Das ist eine Möglichkeit, Trigger zu schreiben, nicht unüblich.
Woher Wert kommt, ist dem Trigger egal. Alles was Werte schreiben kann, kann genutzt werden das Feld zu beschreiben und damit den Triggerwert zu vermeiden.
Wenn man den Trigger verwendet, benötigt man kein anderes Verfahren.
Wenn man ein anderes oder verschiedene Verfahren verwendet, selbst SQL console, stellt der Trigger einen eindeutigen Wert sicher.
"Wie man die richtige ID findet?" Damit meinst Du den ID Wert, der gesetzt wurde?
Das geht auch unter Firebird glaube ich mit Returning Clause, die liefert nach dem Insert den Wert (oder auch andere zurück). Das muss natürlich vom Provider unterstützt werden. Weiß ich bei Firedac nicht.

[Hansa]

Zitat:

Zitat von jobo (Beitrag 1318283)

Der Trigger ist so geschrieben, dass er nur selbst einen Wert vergibt, wenn das Feld noch NULL ist. Das ist eine Möglichkeit, Trigger zu schreiben, nicht unüblich.

Ach so geht das ? :stupid: Hier wird aber jetzt gesagt, dass in IBExpert der Trigger zuschlägt wie üblich und in Delphi/FireDAC eben nicht. Wie soll das gehen ? Dazu bräuchte ich eine Erklärung. Das kann doch alles nicht sein. Der Trigger ist gnadenlos und schlägt anhand der Bedingungen zu. Man kann also nur den Wert eines Feldes auf nicht NULL (dadurch halt den Trigger aushebeln bei entsprechender Abfrage auf NULL ) setzen oder den Trigger deaktivieren.

[jobo]

Zitat:

Hier wird aber jetzt gesagt, dass in IBExpert der Trigger zuschlägt wie üblich und in Delphi/FireDAC eben nicht. Wie soll das gehen ?

Weiß ich auch nicht. Wo wird das gesagt?
Ein Trigger ist ein Trigger. Man könnte ihn disablen. Hast Du ja auch schon erwähnt. Aber dann gehört man geteert usw.
Vielleicht ein Missverständnis? Er schlägt nicht zu, weil er brav mit fertigen Daten gefüttert wird?

[Hansa]

Thread wird langsam auch zu lange.

in #52 steht das :

Zitat:

Zitat von ATS3788 (Beitrag 1318257)

Danke
Nur wenn ich das in der Datenbank mit IBExpert mache,
geht das, mit Firedac nicht. OK mal sehen.:pale:

Before is Active


as
begin
if (new.counter is null) then
new.counter = gen_id(gencounter,1);
end

Tja, und jetzt ?

[jobo]

Zitat:

Zitat von Hansa (Beitrag 1318291)

Thread wird langsam auch zu lange.
in #52 steht das
Tja, und jetzt ?

Also das steht in #47, aber die Formulierung ist etwas schwammig: Dann geht "das"
Einen weiter #48 steht, dass es doch geht (was auch immer).
Ich kann zu Firedac nichts sagen, nie benutzt. Aber offenbar kann man auch damit die Werte setzen.
Der Trigger geht sicherlich und greift, wenn man es mit Firedac nicht hinbekommt.

[TBx]

Zitat:

Zitat von Hansa (Beitrag 1318280)

Dies würde bedeuten, wenn man folgendes macht :

Delphi-Quellcode:

   FDTable1COUNTER.AutoGenerateValue := arAutoInc;

dann wird automatisch die NULL überschrieben ?

Nein, umgekehrt.
Im Normalfall überträgt Firedac einen Wert. Das arAutoInc teilt FireDac mit, daß der Wert automatisch gesetzt werden soll und deswegen NULL zu übertragen ist (wodurch der Trigger dann auch greift).

Damit dürften dann alle Klarheiten endgültig beseitigt sein.