PDA

View Full Version : Sync DB2 -> MS SQL 2005



Seiten : 1 [2]

Fuerchau
11-05-07, 08:34
Je nach Anwendung sind Journale sehr aufwändig, da eine Vielzahl von nicht nötigen Änderungen protokolliert werden.

Es gibt da Anwendungen, die häufig Pseudo-Updates durchführen um Sperren zu realisieren.
Also wird da ein einzelnes Feld als Sperrkennzeichen verwendet, so dass z.T. mehrere 1000 Updates pro Tag ohne tatsächliche Änderung der Daten erfolgt.

Trigger können da eher auf tatsächliche und/oder relevante Änderungen prüfen und somit das Datenaufkommen zur Synchronisation erheblich reduzieren.

Juergen_G
11-05-07, 08:58
Danke für die zahlreichen Antworten.

Ich habe hier mal eine erste Version eines SQL-Triggers erstellt.

create trigger testUpdate1
after update
on lib/table
referencing new as New
for each row
mode db2row

insert into Lib/table_a (NR, TEXT1, DECIMAL1, trntype)
values (New.Nr, New.Text1, New.Decimal1, 'U')

Die Tabelle table_a hat alle Felder bis auf das zusätzliche Feld trntype - hier möchte ich die insert, update, und delete speichern.

Wie kann man einen Datensatz von einer Quell- in eine Zieltabelle komplett inserten ohne jedes Feld einzeln anzugeben, zusätzlich soll manuell das trntype-Feld gefüllt werden. [?]

Wenn man zusätzlich noch den User und das Datum integrieren kann, hat man mit einfachen Mitteln ein Journal erstellt.

Danke Jürgen;)

Fuerchau
11-05-07, 09:54
Ohne alle Felder anzugeben geht das nur im

"insert into dest select * from source"

Da du aber den Puffer "new.*" angeben und nur den aktuellen Satz willst, musst du alle Felder einzeln angeben.

Juergen_G
11-05-07, 10:52
hmm.. - Schade so muß jedes Feld angesprochen werden.

Bietet SQL (nicht RPG) eine Funktion welche den User und oder Timestamp über welchem der Insert, Update oder Delete Trigger aufgerufen wurde zurück liefert?

Fuerchau
11-05-07, 10:56
"current user" oder "user"
"current timestamp"
"current date"
"current time"
"now()"

BenderD
11-05-07, 12:26
Hallo,

das kann man sicher auch so trickreich umgehen (ich habe nicht im Kopf, was SQL in diesem trigger zu select new.* sagen würde...), aber was soll der Geiz?
Current_Timestamp kann man bei einem create table auch als default vernageln, dann steht der automatisch drin, wenn man das Feld nicht füllt.

mfg

Dieter Bender


hmm.. - Schade so muß jedes Feld angesprochen werden.

Bietet SQL (nicht RPG) eine Funktion welche den User und oder Timestamp über welchem der Insert, Update oder Delete Trigger aufgerufen wurde zurück liefert?

Fuerchau
11-05-07, 13:30
@Dieter
Da ein Select immer auf eine Tabelle geht, kann eben "new.*" nicht selectiert werden um den Insert abzukürzen.

camouflage
11-05-07, 13:59
meine Frage geht in eine ähnliche Richtung:

Habe ein Infofile (Text) mit fester Recordlänge, d.h. Bausteinnummer+n Zeilen. Ich möchte nun dieses in den SQL Server bringen via DTS. Soweit so gut DTS funktioniert ja auch, nur der Text zickt herum. Ich habe auf der i5 ein Text feld generiert mit 9000 Stellen und setze die Zeilen mit CAT und <br> zusammen. Im SQL Server hab ich eine Länge des Textfeldes von 16 Stellen und keine Daten im Text. Teste ich das Feld in den DTS Transformation sehe ich die Daten. Was läuft hier falsch?
Edit: OS V5R4/SQL-2000

Hat sich erledigt. Alles ok! Ist halt alles Ansichtssache.

BenderD
11-05-07, 14:10
@Baldur: das mit dem (unsinnigen) select kriegt man mit from sysibm.sysdummy1 noch gebogen, aber zu dem new.* lässt es sich wohl nicht überreden...


@Dieter
Da ein Select immer auf eine Tabelle geht, kann eben "new.*" nicht selectiert werden um den Insert abzukürzen.