[mssql] Hij dropt een tabel niet

[_Thanatos_]

Ik heb de volgende code (stukje ervan dan):

code:

SELECT * FROM #TempXML
DROP TABLE #TempXML
SELECT * INTO #TempXML FROM OPENXML(...bla..)

Het DROP TABLE statement voert ie niet uit, omdat ie op de 3e regelt zeurt dat #TempXML al bestaat, ook al staat 1 regel erboven dat ie em weg moet gooien.

Ik weet, je kan er GO onder zetten om het uitvoeren ervan te forceren, maar als ik dat doe, vergeet ie ook alle variabelen die erboven staan. En die heb ik toch echt nodig...

Ik wil dus eigenlijk dat de bovenste SELECT uitgevoerd wordt, een recordset teruggeeft, en dat de SELECT INTO ook gaat werken met die tabel.

[Verwijderd]

je probeert een open table te droppen . ..

eerst sluiten ???

[Verwijderd]

Gewoon die 2e temp tabel een andere naam geven is geen optie?

[_Thanatos_]

Ik heb nu nieuwe (unieke) namen gegeven aan die temp tabellen, maar echt netjes is het natuurlijk niet. Het zou mooier zijn als ie een tabel gewoon dropt als ik dat wil

Btw Skizmo: openen en closen is alleen van toepassing op cursors, niet op tabellen.

[Verwijderd]

Op dinsdag 16 juli 2002 14:03 schreef _Thanatos_ het volgende:
Ik heb de volgende code (stukje ervan dan):

code:

SELECT * FROM #TempXML
DROP TABLE #TempXML
SELECT * INTO #TempXML FROM OPENXML(...bla..)

Het DROP TABLE statement voert ie niet uit, omdat ie op de 3e regelt zeurt dat #TempXML al bestaat, ook al staat 1 regel erboven dat ie em weg moet gooien.

wat WIL je nou eigenlijk doen?
-- eerst wat in #TempXML stoppen
-- Dan er iets uit selecteren
-- Dan er weer iets instoppen

Een temptable is een gewone table, dus als die 2e select into hetzelfde rowformat oplevert als al in #tempxml zit, dan kun je die rows in #tempxml gewoon wegkegelen en met

INSERT INTO #tempxml (fieldlist)
SELECT * FROM OPENXML()

rows toevoegen.

Ik weet, je kan er GO onder zetten om het uitvoeren ervan te forceren, maar als ik dat doe, vergeet ie ook alle variabelen die erboven staan. En die heb ik toch echt nodig...

Ik wil dus eigenlijk dat de bovenste SELECT uitgevoerd wordt, een recordset teruggeeft, en dat de SELECT INTO ook gaat werken met die tabel.

Erm... je gaat een select list teruggeven EN daarna iets in een temptable gooien... klinkt niet echt solide. Wellicht opdelen in meerdere stored procs?

temptables zijn soms niet de beste oplossing btw. Je kunt ook 'Table' variabelen gebruiken in SQLServer 2000, die zijn efficienter, want die worden niet in TempDB gecreeerd maar in memory.

[dusty]

Ik gok het direct uitvoeren op de database van de queries ook niet werkt? Immers heb je dat zelf als eerste geprobeerd.

Uiteraard is het dan ook nog teveel werk om de foutmelding die je daarin krijgt hier te plakken?

achja ....

[_Thanatos_]

dusty:
1) nee, zo test ik al m'n queries voor ze met ASP in zee gaan.

2) wat begrijp je niet aan dat ie zegt dat de tabel al bestaat? Dat is de foutmelding. Wat wil je horen, "Table #TempXML already exists" ofzo?

[Verwijderd]

Op dinsdag 16 juli 2002 22:07 schreef _Thanatos_ het volgende:
2) wat begrijp je niet aan dat ie zegt dat de tabel al bestaat? Dat is de foutmelding. Wat wil je horen, "Table #TempXML already exists" ofzo?

Oh dit is toch niet waar he...

scenario:
- Men opene Query Analyzer.
- Men maakt een connection met de database
- Men typt een query in die een temptable maakt
- Men runt die query, die werkt.
- Men verandert iets aan die query
- Men runt de query opnieuw. Error! #temptable bestaat al!

#temptables worden weggegooid bij het afsluiten van de connection. Als jij ze test in query analyzer dan is de connection niet verbroken DUS bestaat die temptable nog. NOG eens dezelfde temptable creeeren in je query zal resulteren in een foutmelding.

Als je wilt testen, zet dan BOVENAAN een drop table #temptable neer, een GO en dan je query. Sowieso is het handig onderaan je code een drop table #temptable te doen, dus dan zal je query sowieso goed werken na de 1e keer.

[Greyfox]

Volgens mij is een GO na een drop statement verplicht....

[_Thanatos_]

Otis: nee natuurlijk drop ik aan het einde die table wel

Er staat in m'n beginpost ook dat het een deel van m'n code is. Het ging erom dat die drop gewoon niet gedaan wordt.

Greyfox: als dat waar is... daar heb ik wat aan

[Verwijderd]

Op woensdag 17 juli 2002 09:51 schreef Greyfox het volgende:
Volgens mij is een GO na een drop statement verplicht....

Je moet de transaction die gestart wordt door de DROP committen, zie docs over 'DROP'. GO doet dat, maar daar zijn meer statements voor. Dit verschijnsel heet 'implicit transactions'.

Waar het hier om gaat is dat men een temptable denkt te moeten droppen IN een stored proc, terwijl die temptable aan het eind wordt gedropt, automatisch. Wat riekt naar onzorgvuldig design van de stored proc en nog onzorgvuldiger gebruik van de temptable. Nu is dat al meerdere keren gevraagd hier maar daar komt geen antwoord op. Mja...

[Verwijderd]

Op woensdag 17 juli 2002 09:56 schreef _Thanatos_ het volgende:
Otis: nee natuurlijk drop ik aan het einde die table wel

EN je dropt hem in het midden, lijkt me raar.

Er staat in m'n beginpost ook dat het een deel van m'n code is. Het ging erom dat die drop gewoon niet gedaan wordt.
Greyfox: als dat waar is... daar heb ik wat aan

Nee, dan heb je daar niets aan, want een 'go' is niet te executeren IN een stored proc, daar dit een batch delimiter is.

[_Thanatos_]

Nee, dan heb je daar niets aan, want een 'go' is niet te executeren IN een stored proc, daar dit een batch delimiter is.

Mja, ik kan het in ieder geval dus wel in twee (of meer) stukken hakken, dan is het opgelost.

[Verwijderd]

Op woensdag 17 juli 2002 10:10 schreef _Thanatos_ het volgende:

[..]

Mja, ik kan het in ieder geval dus wel in twee (of meer) stukken hakken, dan is het opgelost.

Als je in stuk 2 de data in de temptable van stuk 1 wilt lezen kan dat niet natuurlijk. de temptable is weg na het einde van de stored proc van deel 1.