Plateforme Level Extreme
Abonnement
Profil corporatif
Produits & Services
Support
Légal
English
Syntax qustion when creating TEMP table on the fly
Message
De
17/04/2003 12:37:20
 
 
À
17/04/2003 11:15:35
Information générale
Forum:
Microsoft SQL Server
Catégorie:
Stored procedures, Triggers, UDFs
Divers
Thread ID:
00778391
Message ID:
00778916
Vues:
13
>So for now, my problem is solved...but anything that you can think of to simplify or streamline this would be great.

yeah, ditch the generic stuff and write a generator that will create auditing features that are specific to each table.

-Mike

>Hi, Michael...
>
>In a nutshell, I'm trying to do the following any time an UPDATE is done...
>
>- Take the INSERTED and DELETED tables in an UPDATE trigger, and 'pass' them on to a stored proc.
>
>- The stored proc [a generic one] will analyze the INSERTED and UPDATED tables, and will post to an application audit trail log table as necessary.
>
>Because INSERTED and DELETED are only visible inside a trigger [at least that's my understanding], and since I can't find a way to 'pass' them to a stored proc....I was initially doing a...
>
>SELECT * INTO #TEMPINSERTED FROM INSERTED
>SELECT * INTO #TEMPDELETED FROM DELETED
>
>
>...and then the stored proc that I would call at the end of the trigger [called LOGCHANGES] would read #TEMPINSERTED and #TEMPDELETED.
>
>There were two problems with that...first was our DBA freaked at the notion of a SELECT *, even on a one row system table. The second problem, more a practical one, is that a few columns in our DB are TEXT and IMAGE...and those can't be used in a SELECT * FROM INSERTED [you wind up getting an error]. The list of columns for every table that we wish to 'log' are stored in an application data dictionary, so I want to read out of that application DD and dynamically build a [pardon the VFP syntax]
>
> SELECT &cFieldList INTO #TempInserted FROM Inserted
>
>Since you can only do this with EXEC, and since EXEC blows away any temp table that's referenced in the statement....that's when I posted my question.
>
>The response I received from Roman seems to work. Everything I'm doing to make this work seems like a fair amount of gymnastics, but it does seem to work. I was able to simulate 50 concurrent updates this morning, with no real performance impact.
>
>So for now, my problem is solved...but anything that you can think of to simplify or streamline this would be great.
>
>Thanks,
>Kevin
Michael Levy
MCSD, MCDBA
ma_levy@hotmail.com
Précédent
Suivant
Répondre
Fil
Voir

Click here to load this message in the networking platform