Firebird Embedded + AUTOINC

[jobo]

Zitat von Bernhard Geyer:

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 von jobo:

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

Jojo...

Zitat von Perlsau:

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

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.

Before is Active


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

[ATS3788]

Das

   FDTable1COUNTER.AutoGenerateValue := arAutoInc;

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 ? 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.