Identificering af TEMP tabel

SQL serveren sørger selv for at give unikt navn til temp tabeller. Derfor skal du oprette temp-tabeller selv inden, de bruges og sørge for, at de bliver fjernet efter brug. Det er kun dit eget script og kaldte scripts, som kan få fat i gen.

Det jo lige det. Men spm. gik på HVORDAN jeg vha. T-SQL kunne se om der var oprettet en bestemt temp-tabel.
Humlen er, at jeg skal kommunikere data ned i en trigger. Og jeg kan i denne ikke være 100% sikker på at temp-tabellen er oprettet.

Hvordan har du tænkt dig at få fat i den temp-tabel i triggeren?
Hvis temp-tabellen er oprettet med #Tabel, så tror jeg ikke, at du kan. Hvis du opretter den med ##Tabel, så bliver det en global temp-tabel, men så kan alle andre også få fat i den.

Hvis temp tabellen bliver oprettet uden for en procedure, så burde den kunne ses af alle procedurer/triggere der bliver kaldt for samme session.
En ##tabel kan desværre ikke bruges, da det giver samme problemstilling som ved brug af en alm. tabel.

Kan du ikke bare oprette den temptabel i en procedure inden, du foretager det, som udløser den trigger, der skal bruge den?

Det vil jeg også gøre. Men problemet opstår hvis jeg vil opdatere min tabel med trigger uden om den procedure.
Jeg ved at der skal oprettes en temptabel og min nærmeste kollega ved det. Men hvad nu om et halvt år, eller hvis andre skal rette data på tabel-niveau. Det er det største problem, og det jeg gerne vil håndtere korrekt.

Det er i bla. tilfælde som dette, er Oracle er klart bedre. For her kunne jeg fange er temp-tabellen manglede, og så handle der efter. I SQL Server fejler det hårdt og brutalt, og forhindrer en fornuftig fejlhåndtering.

Er det muligt at sætte en property eller andet, som kun kan ses af den connection som den er sat på?

Jeg løste problemet med en rigtig tabel og @@SPID. Sålænge et job ikke bliver splittet op i flere processer, kan @@SPID bruges til at identificere data hørende til den aktuelle trigger.