select ergebnis in blob speichern. gehts?

[mojo777]

hallo,
ich würde gerne sql abfragen in einem blob-feld speichern. damit will ich eine art history der db-zustände realisieren.
kann das klappen? :-)

gruß

[mkinzler]

Willst du den Abfragestring oder das komplette Ergebnis speichern?
Ich würde aber die History anders lösen: Entweder über Trigger der Schattenkopie erzeugt oder den Datensatz um Datumswert ergänzen und dann nicht ändern sondern neuen Wert erzeugen.

[Flare]

Gegenfrage: Warum sollte es nicht klappen?
Die beste Möglichkeit dies herauszufinden ist doch, es selber zu testen :zwinker:
Oder stelle deine Frage etwas genauer! Willst du wissen wie lange das etwa gut geht bis das Blog voll ist oder wie? :gruebel:

Flare

[mojo777]

@mkinzler: nö. das klappt so nicht. mit *fuck.... hab den begriff vergessen...* naja. also kopie dingens da.... :-)
eine kopie der ganzen db ist hier nicht sinnvoll. da über stored proceduren der alte zustand noch abgefragt werden soll.

@flare. :-) jupp. du hast sicher recht. aber irgendwie war ich gerade zu faul das zu testen. hab gehofft das hat schon jemand mal so gemacht.

dank euch! :-)

[mojo777]

aaaaslo, hier ist der erste (misslungene Test) :-(

SQL-Code:

CREATE PROCEDURE NEW_PROCEDURE 
AS
DECLARE VARIABLE TEMP BLOB SUB_TYPE 1 SEGMENT SIZE 100 CHARACTER SET NONE;
begin
  /* Procedure Text */
  SELECT * FROM EBENEN INTO TEMP;
  /*insert INTO BUCHUNGEN (BU_EBENENSTATUS) VALUES(:TEMP);  */
  suspend;
end^

die fehlermeldung ist

Zitat:

SQL error code = -313.
count of column list and variable list do not match.

komme hier nicht weiter... :-(


mfg

[Elvis]

Zitat:

Zitat von mojo777

@mkinzler: nö. das klappt so nicht. mit *fuck.... hab den begriff vergessen...* naja. also kopie dingens da.... :-)
eine kopie der ganzen db ist hier nicht sinnvoll. da über stored proceduren der alte zustand noch abgefragt werden soll.

Und genau deshalb ist dein Ansatz ... Käse. ;)
Du duplizierst sinnlos Daten, diese sind dann auch noch durch einen Medienbruch unstrukturiert in einem BLOB.
Möglich wären 4 Tabellen

• MetaChangesTypes
  Id
  Name (Insert, Update, Delete)
• MetaTables
  Id
  PrimaryKeyField -> FK zu MetaFieds (hatte ich vergessen)
  Name
  Active (0 oder 1; 0 für gelöscht)
• MetaUsers
  Id
  Name
  Active (0 oder 1; 0 für gelöscht)
• MetaFields
  Id
  MetaTable -> FK zu MetaTables.Id
  Name
  Active (0 oder 1; 0 für gelöscht)
• AuditLog
  Id
  RecordId -> enthält die Id des protokollierten Datensatzes (hatte ich vergessen)
  Field -> FK zu MetaFields.Id
  ChangeType -> FK zu MetaChangeTypes.Id
  ChangeDate
  User -> Fk zu MetaUser.Id
  Value

Wenn du viel Gück hast erinnere ich mich heute abend noch an dich und mit etwas mehr Glück finde ich ein altes FDB Template, indem ich die Systemtabellen ein wenig getunt habe.
Anhand einer Tabelle in der Filterbedingungen stehen wurden so automatisch die MetaXX-Tabellen synchron gehalten und für jedes Feld Trigger generiert, die alle Änderungen des Feldes protokollieren.
Bei einem solchen AuditLog sollte man nie auf die Idee kommen den vollen Objektnamen abzulegen. Dadurch wird das Ding a) unnötig groß und b) werden Abfragen beschissen langsam. ;)

edit: noch mehr Copy&Waste...
edit2: RecordId & PrimaryKeyField vergessen

[mojo777]

:coder2: :nerd:
ahh jah! so wirds also gemacht.
ohne eine strukturierte programmierausbildung fallen manche sachen halt "etwas" schwer. :-)
vielen dank für den ansatz!
obwohl ich mir die abläufe schon ganz gut vorstellen kann, wäre ein beispiel super. :-)


gruß

[Elvis]

Zitat:

Zitat von mojo777

obwohl ich mir die abläufe schon ganz gut vorstellen kann, wäre ein beispiel super. :-)

Wenn die zu protokollierenden Tabellen eine statische Struktur haben, könntest du einfach die Tabellen per Hand füllen.
Welche Tabellen sollen protokolliert werden -> MetaTables
Welche Felder davon -> MetaFields
Die UserIds ambesten OnDemand über eine SProc Abfragen/Einfügen (gibt es User in MetaUser noch nicht -> anlegen).

beim Trigger würde sowas stehen (Vorsicht habe die PSQL Sytax nicht im Kopf, ist also reiner Pseudocode!)

Delphi-Quellcode:

create trigger Audit$$1 -- Die ID aus MetaFields
  before insert or update or delete on ->Tabelle<-
  for each row
as
  userID integer;
  changeType integer;
  newValue varchar(XXX);
begin
  if inserting and
     :New.->FeldName<- is not null then
    changeType := 0;
    newValue   := :New.->FeldName<-;
  elsIf updating and
        (:New.->FeldName<- is not null or :Old.->FeldName<- is not null) then
  
    if :New.->FeldName<- is null then
      changeType := 2;
    elsIf :Old.Feld is null then
      changeType := 0;
    elsIf :New.->FeldName<- != :New.->FeldName<- then
      changeType := 1;
    end if;
  
    newValue := :New.->FeldName<-;
  
  elsIf deleting and
        :Old.->FeldName<- is not null then
    changeType := 2;
    newValue   := null;
  end if;

  if changeType is not null then
    userID := getUser(CurrentUser);-- Die Sproc, die ich oben erwähnte

    INSERT INTO AuditLog
      (
      ,Field
      ,RecordId
      ,ChangeType
      ,ChangeDate
      ,User
      ,Value)
    VALUES
      (1  -- Die ID aus MetaFields
      ,:New.->PrimaryKeyFeldName<-
      ,changeType
      ,SysDate
      ,userId
      ,newValue);
  end if;
end;

Das könntest du dir erstmal einfach aus MetaTables & MetaFields für jedes aktive Feld generieren lassen.


Falls ich die alte DB nicht mehr finden sollte, kann ich ja mal schauen ob ich es aus dem Kopf zusammenkriege (ich habe seeehr selten mit FB zu tun ;) )

edit: hatte den PK des Datensatzes vergessen, sowas passiert wenn man sich irgendwelchen kranken Käsen aus den fingern saugt. :mrgreen: