SQL Server (και άλλες databases)

Απ:Re: AFTER INSERT TRIGGER

axaros — Fri, 22 Jul 2005 17:48:44 GMT

Aris wrote:

Υ.Γ. Καιρός να αναβθμιστείς σε "Ζωγράφος Μεγάλων Επιφανειών"

Το παλεύω ... Το παλεύω ...

Απ:Re: AFTER INSERT TRIGGER

Aris — Fri, 22 Jul 2005 03:54:57 GMT

Μιά χαρά είναι

Εάν θεωρήσουμε ότι ο trigger ξεκινάει implicit transaction, τότε το "κλείνεις" με το commit και επομένως δεν έχεις rollback του insert σου (sic).

Εάν λοιπόν αποτύχει το execute, δεν σε χαλάει

Άρης

Υ.Γ. Καιρός να αναβθμιστείς σε "Ζωγράφος Μεγάλων Επιφανειών"

Απ:Re: AFTER INSERT TRIGGER

axaros — Thu, 21 Jul 2005 22:14:46 GMT

Το παρακάτω δούλεψε :

CREATE TRIGGER tgrExport ON [dbo].[tblTest]
FOR INSERT
AS

DECLARE @IId BigInt
DECLARE @IDes nvarchar(50)

SET @Iid = (Select Id From Inserted)
SET @IDes = (Select Des From Inserted)

COMMIT TRANSACTION
EXECUTE Laptop.[TEST DATABASE].dbo.spInsertTestValues @IId,@IDes

με linked server και RPC χωρίς να χάνω ποτέ την εγγραφή που ενεργοποιεί τον trigger.
(Κάνω export σε άλλο instance,βάση σε άλλο μηχάνημα)
Το ξέρω ότι δεν είναι ότι καλύτερο αλλά τι λέτε;

Re: AFTER INSERT TRIGGER

Aris — Tue, 19 Jul 2005 20:31:27 GMT

axaros wrote:

...

Στην περίπτωση trigger η ενημέρωση είναι άμεση αλλά εάν χρησιμοποιήσω ένα linked sevrver (σε άλλο instance) και distributed transaction δεν έχω τρόπο να εγγυηθώ ότι αν κάτι πάει στραβά η εγγραφή στον δίκο μου πίνακα (που ενεργοποιεί και τον trigger) δεν θα γίνει rollback ...

Οπότε κατέληξα στη λύση trigger για ενημέρωση μίας άλλης βάσης στο τοπικό instance με τη χρήση SAVEPOINT.

Ακριβώς.

Ή στο ίδιο instance (αποτυχία σε ένα μηχάνημα) ή με την λύση που σου πρότεινα (messaging λογική σε δύο μηχανήματα).

Άρης

Re: AFTER INSERT TRIGGER

axaros — Tue, 19 Jul 2005 19:26:34 GMT

Άρη,
δεν έχεις άδικο όσον αφορά την χρήση της ίδιας βάσης ... Φυσικά θα μπορούσε ο συνεργάτης μου να διαβάζει κατευθείαν από το δικό μου σύστημα τις unexported εγγραφές τις οποίες και χρειάζεται για να τις εμφανίσει στο ευρετήριο του και με μία batch διαδικασία ή ένα service που τρέχει ανά x χρονικά διαστήματα να "πέφτουν" οι εγγραφές στη δική του βάση και να μαρκάρονται σαν exported στη δική μου.

Δυστηχώς για άλλους λόγους οι συγκεκριμένες προτάσεις δεν ήταν αποδεκτές ...
Εν ολίγοις ξέχασε τες.

Στην περίπτωση του serviced component αυτό που γινόταν ήταν, για να εμφανίσει σε ένα ευρετήριο στην εφαρμογή του τις εγγραφές που "έπεφταν" στο δικό μου σύστημα καλούσε το console app κλπ κλπ σε άλλο instance σε άλλη βάση σε άλλο μηχάνημα με την όποια καθυστέρηση...

Στην περίπτωση trigger η ενημέρωση είναι άμεση αλλά εάν χρησιμοποιήσω ένα linked sevrver (σε άλλο instance) και distributed transaction δεν έχω τρόπο να εγγυηθώ ότι αν κάτι πάει στραβά η εγγραφή στον δίκο μου πίνακα (που ενεργοποιεί και τον trigger) δεν θα γίνει rollback ...

Οπότε κατέληξα στη λύση trigger για ενημέρωση μίας άλλης βάσης στο τοπικό instance με τη χρήση SAVEPOINT.

Re: AFTER INSERT TRIGGER

Aris — Tue, 19 Jul 2005 01:07:41 GMT

Το extra βήμα έχει σαν αποτέλεσμα την αποσύνδεση της εφαρμογής σου από την εφαρμογή του συνεργάτη σου. Είναι μιά λογική messaging, ουσιαστικά.

Εάν καμμία καθυστέρηση δεν είναι αποδεκτή, γιατί δεν χρησιμοποιείτε, και οι δύο, την ίδια βάση;
Εάν κάποια καθυστέρηση είναι αποδεκτή αλλά πρέπει να υπάρχει πλήρης έλεγχος των ενημερώσεων, τότε η προτεινόμενη λύση:
- εξασφαλίζει την ακαιραιότητα των δεδομένων
- απεμπλέκει τα δικά σου transactions από τις ανάγκες ενημέρωσης του άλλου συστήματος (το ενημερώνεις μόνον όταν είσαι εντάξει και μπορείς)
- Επιταχύνεις την δική σου λειτουργία, ειδικά εάν κάνεις τα βήματα ενημέρωσης σε άλλο thread
- έχεις την δυνατότητα να τον ενημερώσεις σε batch mode (π.χ. κάθε 10 εγγραφές)

Το κόστος (ένα update και ένα read από την άλλη βάση) δεν είναι τραγικό, εάν συγκριθεί με το κόστος ενός πλήρους rollback εάν κάτι δεν πάει καλά στην άλλη βάση.

Άρης

Re: AFTER INSERT TRIGGER

axaros — Mon, 18 Jul 2005 22:51:59 GMT

Aris wrote:
Επανέρχομαι στο ζήτημα της λογικής που πρέπει να υλοποιηθεί:
Στο άλλο thread, είχες πει ότι:

axaros wrote:

Αυτό που θέλω να κάνω είναι σε ένα βήμα να
   1)Διαβάσω ένα set εγγραφών
   2)Να το μαρκάρω σαν exported
   3)Nα το εισάγω σε μία Export βάση

Εάν αυτό ισχύει, και μπορείς να έχεις ένα tri-state flag (Not for export - Under export - Exported), μήπως θα μπορούσες να τροποποιήσεις την σειρά των ενεργειών ώστε να ξεμπλέξει λίγο το θέμα; Δηλαδή:

1. Επιλέγεις τι πρέπει να εξαχθεί, και μαρκάρεις σαν "Under export"

Μου βάζεις ένα έξτρα βήμα ... Γιατί να κάνω update σαν under export ;
Άλλα ούτως ή άλλως το serviced component δουλεύει μια χαρά.

Εάν πάμε στη λογική trigger αλλάζει το πράγμα ...

Βασικά η λύση serviced component "δεν άρεσε" γιατί ο συνεργάτης που θέλει τις πληροφορίες δουλεύει με το Omnis studio και για κάποιο λόγο μου έθεσε ότι δεν μπορεί να μιλήσει με COM. Οπότε καλούσε ένα console app με κάποιες παραμέτρους και αυτό με τη σειρά του έκανε το call στο serviced component με αποτέλεσμα να υπάρχει μία καθυστέρηση στην ενημέρωση των βάσεων. Επειδή όποια εγγραφή "πέφτει" στο σύστημα μου πρέπει να εμφανίζεται και στο δικό του (συγκεκριμένα τα παραπάνω γίνονταν όταν καλούσε κάποια εύρεση στην εφαρμογή του) και κάτω από αυτούς τους όρους η λύση trigger κρίθηκε καλύτερη.

Υπό αυτό το σενάριο όταν "πέφτει" μια εγγραφή στο σύστημα μου ενημερώνεται και το δικό του ...

Re: AFTER INSERT TRIGGER

Aris — Mon, 18 Jul 2005 22:34:04 GMT

Επανέρχομαι στο ζήτημα της λογικής που πρέπει να υλοποιηθεί:
Στο άλλο thread, είχες πει ότι:

axaros wrote:
Αυτό που θέλω να κάνω είναι σε ένα βήμα να
   1)Διαβάσω ένα set εγγραφών
   2)Να το μαρκάρω σαν exported
   3)Nα το εισάγω σε μία Export βάση

Εάν αυτό ισχύει, και μπορείς να έχεις ένα tri-state flag (Not for export - Under export - Exported), μήπως θα μπορούσες να τροποποιήσεις την σειρά των ενεργειών ώστε να ξεμπλέξει λίγο το θέμα; Δηλαδή:
1. Επιλέγεις τι πρέπει να εξαχθεί, και μαρκάρεις σαν "Under export"
2. Κάνεις την εισαγωγή στην άλλη βάση
3. Εξετάζεις το αποτέλεσμα του [2], διαβάζοντας τι μπήκε (ή τρως Timeout)
4. Ανάλογα με το [3], αλλάζεις το "Under export" σε "Exported"
Τα [2],[3],[4] θα μπορούσαν να παίζουν και σε άλλο Thread.

Η [1] δεν έχει πρόβλημα transaction (ως προς την άλλη βάση). Εάν αποτυγχάνει τοπικά (ως προς την πρώτη βάση), το διαχειρίζεσαι τοπικά
Τα άλλα στάδια παίζουν ανεξάρτητα. Όταν πάρεις αποτέλεσμα, ή ενημερώνεις την πρώτη βάση ότι "ξεμπέρδεψες" ή επαναλαμβάνεις.

Ελπίζω ότι έχω καταλάβει σωστά το πρόβλημα.
Εάν όχι, ...

Άρης

Re: AFTER INSERT TRIGGER

axaros — Mon, 18 Jul 2005 19:57:28 GMT

Άρη καλημέρα ,
Από το άρθρο :
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/acdata/ac_8_md_06_4qcz.asp

A trigger always operates as if there were an outstanding transaction in effect when the trigger is executed. This is definitely true if the statement firing the trigger is in an implicit or explicit transaction. It is also true in autocommit mode. When a statement begins executing in autocommit mode, there is an implied BEGIN TRANSACTION to allow the recovery of all modifications generated by the statement if it encounters an error. This implied transaction has no effect on the other statements in the batch because it is either committed or rolled back when the statement completes. This implied transaction is still in effect, however, when a trigger is called.

Όσον αφορά το serviced component απλά ήθελα να δοκιμάσω την περίπτωση που πάει κάτι στραβά για αυτόν ακριβώς το λόγο έκανα rollback στο τέλος.
Δεν θέλω να κάνω κάτι με κάποιο αποτυχημένο transaction.

Παρεπιπτόντως ακόμα δεν έχω βρει κάτι για την περίπτωση Sybase. Από SQL server σε SQL Server δουλεύει μια χαρά ...

Εάν τώρα εναλλακτικά το ίδιο πρόβλημα (export δεδομένων από μία βάση σε μία άλλη) το λύσω με trigger θέλω οπωσδήποτε η εγγραφή που (γίνεται Insert) να καταχωρείται πάντα και εάν συμβεί κάτι (π.χ. χάνω στιγμιαία την τοπική σύνδεση δικτύου) να γίνεται rollback μόνο το action του trigger.

Για local transactions βρήκα ότι αυτό γίνεται με SAVEPOINTS.
Στην περίπτωση που χρησιμοποιήσω linked server και distributed transaction από ότι διάβασα δεν υπάρχει υποστήριξη για SAVEPOINTS.

Re: AFTER INSERT TRIGGER

Aris — Sun, 17 Jul 2005 04:28:26 GMT

Τι εννοείς "αποτυχία"; Αφού η εγγραφή έχει μπει επιτυχώς...

Η εισαγωγή γίνεται στα πλαίσια ευρύτερου Transaction που μπορεί να αποτύχει αργότερα;
Σε αυτή την περίπτωση, μήπως πρέπει να τροποποιήσεις την σειρά των ενεργειών;

Είναι η περίπτωση με τον Adaptive Sever Anywhere; Μου έχει μείνει η απορία γιατί ήθελες να έχεις ένα αποτυχημένο transaction ...

Άρης

Re: AFTER INSERT TRIGGER

axaros — Sun, 17 Jul 2005 03:38:53 GMT

Όχι ακριβώς ...
Θέλω σε κάποιο INSERT να γίνεται triggered η εγγραφή σε κάποιο άλλο πίνακα σε κάποια άλλη βάση αλλά σε περίπτωση αποτυχίας να γίνεται rollback μόνο το action του trigger ...

Βασικά το ζητούμενο είναι ότι και στο αντίστοιχο θέμα στο COM+ forum. Θέλω να κάνω export κάποιες πληροφορίες από μία βάση σε μία άλλη ...

Re: AFTER INSERT TRIGGER

Aris — Sun, 17 Jul 2005 03:02:31 GMT

Μπορείς να είσαι πιό σαφής και αναλυτικός στο τι θες να κάνεις;

Από τον T-SQL κώδικα, το μόνο που καταλαβαίνω είναι ότι θες να εισάγεις κάποια από τα εισαχθέντα στοιχεία και κάπου αλλού ...

Άρης

Re: AFTER INSERT TRIGGER

axaros — Sat, 16 Jul 2005 18:36:18 GMT

Το μόνο που βρήκα είναι η χρήση SAVEPOINT το οποίο δουλεύει μόνο για local transaction. Για distributed υποθέτω ότι έχασα ;
Μπορεί να με βοηθήσει κάποιος ;

Re: AFTER INSERT TRIGGER

axaros — Wed, 06 Jul 2005 00:46:05 GMT

Τρίχες δουλεύει ... Παιδιά τα φώτα σας ....

Re: AFTER INSERT TRIGGER

axaros — Wed, 06 Jul 2005 00:23:38 GMT

Συγνώμη που βιάστηκα αλλά το transaction είναι distibuted με χρήση linked server.
Το παρακάτω statement κάνει αυτό που θέλω αλλά ζητώ τη γνώμη σας :

CREATE TRIGGER tgrTest ON dbo.tblSourceTest
AFTER INSERT
AS

SET XACT_ABORT ON
BEGIN DISTRIBUTED TRANSACTION
Insert Into [PC-PAVRM].[TEST DATABASE].dbo.tblTest
Select Id,Des From Inserted
Commit TRAN

COMMIT TRANSACTION