[SQL server 7] tabelnaam beginnen met een hekje.... (#)

[Verwijderd]

Mijn collega (echt, ik was het niet) heeft in een SQL-server database alle tabellen hernoemt van "tabel" naar "#tabel". Nadat hij de Enterprise manager had afgesloten en weer opgestart, kwamen de tabellen niet meer in beeld. In Sysobjects staan ze echter nog wel. Het is niet mogelijk om "SELECT * FROM #tabel" te doen, dan geeft hij aan dat dat geen geldige naam is. Waarschijnlijk is het hekje (als eerste karakter) dus een preserved character, die tabellen onzichtbaar maakt, maar hij geeft daar geen waarschuwing voor.

Nou bleek (ramp ramp ramp) dat de betreffende SQL-server niet gebackupped werd (niet onze verantwoordelijkheid gelukkig). Conclusie, we zijn een hele berg met data kwijt. Heeft iemand een idee? Eeuwige dank ligt voor het oprapen!

[whoami]

Een tabel die begint met #is een temporary table.

[Verwijderd]

Geen id, maar met
SELECT * FROM [#tabel]
kom je normaal om reserved words in tabel en kolomnamen heen.

[Verwijderd]

In SQL-Server 2000 kun je 'm niet eens meer hernoemen naar # maar in 7 helaas nog wel. Dat het een temporary tabel is zou wel kunnen, maar daar kan ik nog steeds niets mee. De blokhaken heb ik ook al geprobeerd, die geven geen oplossing.

[whoami]

Een temp table blijft maar bestaan zolang de sessie geldig is. Als je geen backups hebt, vrees ik er een beetje voor...

[Coltrui]

Misschien een domme vraag maar kan je niet mbv generate script de tempdb namaken en dan de data overpompen?

[whoami]

Tja, als je niet meer ad data kunt, kan je de data ook moeilijk overpompen.

Wat bezielde die collega trouwens om die tabellen te gaa hernoemen.

[Coltrui]

whoami schreef op 10 April 2003 @ 13:57:
Tja, als je niet meer ad data kunt, kan je de data ook moeilijk overpompen.

Uiteraard Maar is dat zo? Staan ze niet meer in de tempdb-database?

[whoami]

Creating and Modifying a Table
After the database design has been determined, the tables that will store the data in the database can be created. The data is usually stored in permanent tables. Tables are stored in the database files until they are deleted and are available to any user who has the appropriate permissions.

Temporary Tables
You can also create temporary tables. Temporary tables are similar to permanent tables, except temporary tables are stored in tempdb and are deleted automatically when no longer in use.

The two types of temporary tables, local and global, differ from each other in their names, their visibility, and their lifetimes. Local temporary tables have a single number sign (#) as the first character of their names; they are visible only to the current connection for the user; and they are deleted when the user disconnects from computers running Microsoft® SQL Server™. Global temporary tables have two number signs (##) as the first characters of their names; they are visible to any user after they are created; and they are deleted when all users referencing the table disconnect from SQL Server.

For example, if you create a table named employees, it can be used by any person who has the security permissions in the database to use it, until it is deleted. If you create a local temporary table named #employees, you are the only person who can work with the table, and it is deleted when you disconnect. If you create a global temporary table named ##employees, any user in the database can work with this table. If no other user works with this table after you create it, the table is deleted when you disconnect. If another user works with the table after you create it, SQL Server deletes it when both of you disconnect.

Kan jouw collega nog die temp. tables accessen, of heb je de connectie met de DB al eens verbroken?

[ Voor 3% gewijzigd door whoami op 10-04-2003 14:05 ]

[EfBe]

Wezen schreef op 10 april 2003 @ 14:01:
[...]
Uiteraard Maar is dat zo? Staan ze niet meer in de tempdb-database?

Nee, zodra de connectie wordt gesloten verdwijnen de temptables, sterker als een scope gesloten wordt worden de temptables in die scope (bv stored proc) gesloten, tenzij je de table met ## hebt geprefixed.

Het is toch elke keer weer wonderlijk hoe de grootst mogelijke prutsers toegang krijgen tot toetsenborden.

[Dennis van der Stelt]

Ik zou ook proberen dat data over te pompen naar echte tabellen. Moet je wel opletten dat je niet al je auto-generated-primary key's verliest, i.v.m. foreign keys... Dus eerst identity op PK tabellen uitzetten en later pas aanzetten ofzo.

En probeer eens dbo. ervoor ofzo? dbo.#tabelnaam ??? En dat eventueel weer in blokhaken? [dbo].[#tabelnaam] ???

[Verwijderd]

whoami schreef op 10 April 2003 @ 13:52:
Een temp table blijft maar bestaan zolang de sessie geldig is. Als je geen backups hebt, vrees ik er een beetje voor...

Daar ben ik ook bang voor. Gelukkig bestaan er nog wat Excel-sheetjes met een redelijke hoeveelheid data, die we met behulp van wat vertaalslagen om kunnen bouwen naar SQL-server data.

Het vreemde is wel dat de #tabellen nog wel bestaan in sysobjects. Wat bedoel je precies met een sessie en de tijd dat hij geldig is? Eindigt een sessie als je de Enterprice manager afsluit?

Over het waarom: die collega moest wat tabelstructuren wijzigen (extra veldjes erbij, wat velddefinities erbij enzo. Hij wilde de bestaande tabellen even hernoemen, met een scriptje nieuwe tabellen aanmaken en vervolgens de hernoemde tabellen exporteren naar de nieuwe tabellen. Tsja, het kan makkelijker, maar het is een manier. Als hij het nou had hernoemd naar "xxxtabel" was er ook niets aan de hand geweest....

[whoami]

Als de connectie met de DB verbroken is, dan is de sessie teneinde. Als je dus die Enterpise Manager afgesloten hebt, dan ben ik bang dat die tabellen weg zullen zijn.

Die collega heeft ook nog nooit van een alter table gehoord zeker? En trouwens, als hij niet zeker is van z'n zaak, dan is het toch het beste om -voordat je aan de wijzingen begint - ff een backup neemt.
(Ik kan alleen maar EfBe bijtreden...)

[ACM]

Toch vreemd dat SQLServer dan toelaat het naar #blaat te hernoemen en niet om het terug te hernoemen. Kan je het niet in je system-table veranderen, als ze daar nog in staan iig?

En als ze in de system-tables nog staan na het afsluiten van de enterprise manager, zouden ze dan niet ook gewoon nog steeds bestaan, alleen door naming-convention-opvolging niet getoond worden in de manager? Btw, kan je ze ook niet als select * from "#tabel" aanspreken? Ik mag iig hopen dat SQLServer niet alleen naar de naam kijkt om te bepalen of iets een temptable is of niet

* ACM sqlserver-n00b

[ Voor 11% gewijzigd door ACM op 10-04-2003 14:24 ]

[Verwijderd]

Tsja, erg jammer, de data is verloren gegaan. Gelukkig waren we nog in een beta-versie van het programma bezig, dus erg heel erg schadelijk is het niet, het grootste deel van de data kunnen we reconstrueren, al is dat wel redelijk veel werk. Maar ja, wie heeft er nooit een foutje gemaakt waardoor je een dagje extra werk moest doen. In ieder geval weer wat geleerd vandaag. Ik moet zeggen dat het mij vast ook wel had kunnen overkomen. (hoewel, een hekje?? dat zou ik niet zomaar gebruiken geloof ik). Ik zal de collega een cursusje ALTER TABLE geven.

ACM: tsja, in SQL-server 2000 kan het ook niet meer, daar is dat netjes afgetimmerd. In SQL-server 7 mag je zomaar de tabelnaam wijzigen...

[Annie]

Als de table nog bestaat in sysobjects dan kan je deze afaik nog wel terughalen. Hiervoor moet je echter wel voldoende rechten op de server hebben om ad hoc updates op de systables te doen.
Voer hiervoor onderstaande commando's 1 voor 1 uit op de database.

SQL:

EXEC sp_configure 'allow', 1

RECONFIGURE WITH OVERRIDE

UPDATE dbo.sysobjects 
SET [name] = 'tabelletje' 
WHERE [name] = '#tabelletje'

EXEC sp_configure 'allow', 0

RECONFIGURE WITH OVERRIDE

[ Voor 7% gewijzigd door Annie op 10-04-2003 14:47 ]

[kenneth]

Verwijderd schreef op 10 April 2003 @ 14:40:
Maar ja, wie heeft er nooit een foutje gemaakt waardoor je een dagje extra werk moest doen.

Fouten maken is niet erg, een onherstelbare fout maken is ernstig, een onnodige fout bijna onvergeeflijk.

[EfBe]

Ik zat hier nog even over na te denken, maar het renamen van een table door het van een '#' prefix te voorzien zou de table dan moeten moven naar tempdb ipv dat deze wordt gerenamed. Dat lijkt me onwaarschijnlijk. Ik denk dus dat de tables nog wel bestaan maar niet zichtbaar zijn, omdat alle tables met een # altijd in de tempdb staan. Ik ga dit hier ff testen op mn sqlserver 7 testbak

[EfBe]

Nou je hebt mazzel. Ik heb een testtable gerenamed naar #testtable en die staat daarna gewoon in sysobjects, met de nieuwe naam, '#testtable'.

Je kunt er dan niets mee, maar met het scriptje van annie hierboven kun je ze weer terugrenamen. (dat scriptje werkt hier overigens niet, ben ingelogd als sa. Hij roept 'Ad hoc updates to system catalogs are not enabled. The system administrator must reconfigure SQL Server to allow this.'. Naja. )

En daarna die collega van je promoveren tot chef printerpapier.

edit:

ff scrippie patchen

code:

EXEC sp_configure 'allow', 1
RECONFIGURE WITH OVERRIDE
GO
UPDATE dbo.sysobjects 
SET [name] = 'tabelletje' 
WHERE [name] = '#tabelletje'
GO
EXEC sp_configure 'allow', 0
RECONFIGURE WITH OVERRIDE
GO

[ Voor 49% gewijzigd door EfBe op 10-04-2003 20:31 ]

[Annie]

EfBe schreef op 10 april 2003 @ 20:27:
Nou je hebt mazzel. Ik heb een testtable gerenamed naar #testtable en die staat daarna gewoon in sysobjects, met de nieuwe naam, '#testtable'.

Dat vermoeden had ik dus ook al aangezien de TS vermeldde dat de table nog wel voorkwam in sysobjects.

EfBe schreef op 10 april 2003 @ 20:27:
(dat scriptje werkt hier overigens niet, ben ingelogd als sa. Hij roept 'Ad hoc updates to system catalogs are not enabled. The system administrator must reconfigure SQL Server to allow this.'. Naja. )

Ik zeg nog zo: "1 voor 1 uitvoeren"

EfBe schreef op 10 april 2003 @ 20:27:
En daarna die collega van je promoveren tot chef printerpapier.