[SQL] Tabel leegmaken

[JMfx]

Op dit moment leeg ik mijn tabel op onderstaande manier:

code:

            Dim cmd As SqlCommand = New SqlCommand("DELETE FROM TABLENAME", con)
            con.Open()
            cmd.ExecuteNonQuery()
            con.Close()

Ik ben er echter niet helemaal zeker van dat dit de juiste manier is om een tabel te legen. Ik zou eerder iets verwachten als Delete * from <table>, maar dat blijkt niet te werken. Ook EMPTY TABLE <table> wat ik op het internet heb gevonden blijkt niet te werken.

Is dit de juiste manier om een tabel leeg te maken (enkel de inhoud; colommen en keys moeten behouden blijven)?

[RAJH]

Kijk eens naar het truncate commando

[BtM909]

Wat voor database heb je nou precies? En ik weet zeker dat als je gaat [google=delete table content <databasetype>] je heeeeel veel werkende voorbeelden krijgt

[Wolfboy]

Gewoon "TRUNCATE TABLE TABLENAME" gebruiken

/laat....

[ Voor 13% gewijzigd door Wolfboy op 01-06-2007 20:30 ]

[KabouterSuper]

uhhmm. "DELETE FROM TABLE" is prima syntax. "DELETE * FROM TABLE" is onzin, aangezien de * iets zegt over de kolommen, terwijl je rijen aan het verwijderen bent.

[ Voor 8% gewijzigd door KabouterSuper op 01-06-2007 20:32 ]

[JMfx]

Een andere vraag: Op dit moment is mijn connectionstring zoals hieronder is weergegeven.

code:

con.ConnectionString = "Data Source=.\SQLEXPRESS;AttachDbFilename='C:\Documents and Settings\Jan\My Documents\Visual Studio 2005\Projects\HistoryAnalysisTool\HistoryAnalysisTool\Data.mdf';Integrated Security=True;User Instance=True"

Voor de uiteindelijke applicatie wil ik echter de connectionstring zo schrijven dat deze de opgegeven database in dezelfde directory als de uiteindelijke exe pakt. Bijvoorbeeld zoiets:

code:

con.ConnectionString = "Data Source=.\SQLEXPRESS;AttachDbFilename='<currentfolder>\Data.mdf';Integrated Security=True;User Instance=True"

Ik weet alleen niet hoe ik dit moet schrijven.

[JMfx]

Ik gebruik SQL Server (vandaar het SQLcommand ). Het huidige command werkt goed, alleen ik had het gevoel dat er een andere betere methode moest zijn. De google resultaten vind ik niet erg duidelijk op dit gebied, ook niet de link die is gegeven. Ik zal eens kijken naar TRUNCATE.

[KabouterSuper]

Definieer beter eens? Bedoel je sneller? Een TRUNCATE is vele malen sneller, hoewel je dit pas echt wat oplevert als je tabel 10.000+ rijen heeft. Houdt wel in de gaten dat het TRUNCATE commando heel iets anders doet dan een DELETE, ook al is het uiteindelijke resultaat in beide gevallen een lege tabel.

[JMfx]

Het is meer dat ik Delete FROM <table> zie als een verkorting van DELETE FROM <table> WHERE <blabla>. Ik dacht dat er vast een 'beter' commando moest zijn dat gemaakt is om de tabel leeg te gooien.

Je hebt in ieder geval je punt gemaakt, beide commando's zijn prima Ik ga echter wel voor truncate omdat grote tabellen wel kunnen voorkomen in mijn database.

http://msdn2.microsoft.co...ary/aa260621(SQL.80).aspx

[Tanuki]

Let op dat je vaak geen TRUNCATE wilt doen, omdat dan de auto_increment (in geval van MySQL) wordt gereset naar 0. Relaties in andere tabellen zullen dan corrupt raken.

[jvdmeer]

l0c4lh0st schreef op vrijdag 01 juni 2007 @ 21:21:
Let op dat je vaak geen TRUNCATE wilt doen, omdat dan de auto_increment (in geval van MySQL) wordt gereset naar 0. Relaties in andere tabellen zullen dan corrupt raken.

Dit effect valt tocvh mee? Volgens mij blijven de foreign key constraints actief en zal er dus geweigerd worden om de tabel leeg te gooien. De relatie's blijven dus gewoon intact.

De verschillen zijn natuurlijk wel (uit mijn hoofd, cmiiw):
- TRUNCATE kan niet gerollbacked worden (is geen onderdeel van een transactie)
- TRUNCATE moet je tabel-owner voor zijn.

[Tanuki]

jvdmeer schreef op vrijdag 01 juni 2007 @ 21:27:
[...]


Dit effect valt tocvh mee? Volgens mij blijven de foreign key constraints actief en zal er dus geweigerd worden om de tabel leeg te gooien. De relatie's blijven dus gewoon intact.

De verschillen zijn natuurlijk wel (uit mijn hoofd, cmiiw):
- TRUNCATE kan niet gerollbacked worden (is geen onderdeel van een transactie)
- TRUNCATE moet je tabel-owner voor zijn.

Als jij een TRUNCATE doet zijn de relaties van die tabel verloren.
Als jij weer enkele records toevoegt die ID's opleveren die in de andere tabellen staan (en voorheen relaties hadden met de oude records), hebben de nieuwe records dus opeens relaties die je eigenlijk niet wou hebben.

[whoami]

l0c4lh0st schreef op vrijdag 01 juni 2007 @ 21:44:
[...]

Als jij een TRUNCATE doet zijn de relaties van die tabel verloren.
Als jij weer enkele records toevoegt die ID's opleveren die in de andere tabellen staan (en voorheen relaties hadden met de oude records), hebben de nieuwe records dus opeens relaties die je eigenlijk niet wou hebben.

Wat bedoel je, zijn de relaties verloren ? Een TRUNCATE gaat enkel de inhoud van je tabel weggooien, er gaat nies aan de definitie van je tabel veranderen hoor.
Echter, een truncate table zal ook niet gaan werken als die tabel gereferenced wordt door een andere tabel (mbhv foreign key); maw, als er een andere tabel is, waarvan de PK van de tabel die moet getruncated worden, een foreign key heeft naar die tabel, zal sql server die TRUNCATE niet willen uitvoeren dacht ik.

[dusty]

l0c4lh0st schreef op vrijdag 01 juni 2007 @ 21:44:
[...]
Als jij weer enkele records toevoegt die ID's opleveren die in de andere tabellen staan (en voorheen relaties hadden met de oude records), hebben de nieuwe records dus opeens relaties die je eigenlijk niet wou hebben.

Of jij moet leren met FK's te werken, of je moet eens met een RDBMS gaan werken ipv een DBMS.

whoami schreef op vrijdag 01 juni 2007 @ 21:58:
[...]
zal sql server die TRUNCATE niet willen uitvoeren dacht ik.

Correct, tenzij je dus opgeeft om meteen alle records die eraan gelinkt zijn ook uit de database te laten verwijderen. (CASCADE). Echter niet aan te raden

[Tanuki]

whoami schreef op vrijdag 01 juni 2007 @ 21:58:
[...]
Wat bedoel je, zijn de relaties verloren ? Een TRUNCATE gaat enkel de inhoud van je tabel weggooien, er gaat nies aan de definitie van je tabel veranderen hoor.
Echter, een truncate table zal ook niet gaan werken als die tabel gereferenced wordt door een andere tabel (mbhv foreign key); maw, als er een andere tabel is, waarvan de PK van de tabel die moet getruncated worden, een foreign key heeft naar die tabel, zal sql server die TRUNCATE niet willen uitvoeren dacht ik.

Ik quote...

l0c4lh0st schreef op vrijdag 01 juni 2007 @ 21:21:
Let op dat je vaak geen TRUNCATE wilt doen, omdat dan de auto_increment (in geval van MySQL) wordt gereset naar 0. Relaties in andere tabellen zullen dan corrupt raken.

Ik weet toevallig dat dit bij MySQL zo is, dus ik dacht, dat laat ik even weten. Mijn wel gemeende excuses.

[whoami]

Ook in Sql Server wordt de identity counter gereset, echter, dit heeft daar geen invloed op evt relaties, aangezien je dus niet zomaar een truncate kan doen, als die tabel FK's heeft; (behalve dan met die cascade optie die dusty aanhaalt, maar dan heb je ook geen rare resultaten mbt gerelateerder records achteraf, aangezien je de gerelateerde ook mee verwijdered.
(alhoewel ik die cascade optie niet terugvind in BOL:

You cannot use TRUNCATE TABLE on a table referenced by a FOREIGN KEY constraint; instead, use DELETE statement without a WHERE clause. Because TRUNCATE TABLE is not logged, it cannot activate a trigger.

[ACM]

l0c4lh0st schreef op vrijdag 01 juni 2007 @ 21:44:
Als jij een TRUNCATE doet zijn de relaties van die tabel verloren.
Als jij weer enkele records toevoegt die ID's opleveren die in de andere tabellen staan (en voorheen relaties hadden met de oude records), hebben de nieuwe records dus opeens relaties die je eigenlijk niet wou hebben.

Ik snap wat je bedoelt, maar als je het zo doet, dan ben je natuurlijk als programmeur gewoon bugs aan het maken. Als blijkbaar de relaties die er vroeger waren van belang zijn, dan is het sowieso maar de vraag of je wel een delete/truncate had moeten doen. Of wellicht eerst de relaties had moeten verbreken (veld met relaties null maken ofzo), danwel dat onderdeel van je verwijderprocedure moeten maken

Maar als je enkel een truncate doet en dan verwacht dat alle koppelingen naar eerder verwijderde records door het niet meer bestaan van de records aangegeven kunnen worden, dan heb je gelijk dat truncate met zijn auto_increment-reset gevaarlijk is.

whoami schreef op vrijdag 01 juni 2007 @ 23:24:
(alhoewel ik die cascade optie niet terugvind in BOL:

Dat lijkt me ook vrij sterk dat er een cascade-optie voor zou Truncate bestaan, dat is tegenstrijdig met de werking ervan en je quote over triggers suggereert het ook al dat het het er niet is.

[ Voor 14% gewijzigd door ACM op 01-06-2007 23:54 ]

[dusty]

Het klopt cascade bestaat niet voor TRUNCATE. Iemand die de gehele database echter leeg wilt hebben, zal vaak een cascaded delete doen, gevolgd door een truncate.

[Janoz]

JMfx schreef op vrijdag 01 juni 2007 @ 21:05:
Het is meer dat ik Delete FROM <table> zie als een verkorting van DELETE FROM <table> WHERE <blabla>.

Het is eerder andersom. De where toevoeging is eerder een specialisering/verfijning van je query. Bij select kun je hem immers ook gewoon weglaten wanneer je alle rijen terug wilt hebben .

[JMfx]

JMfx schreef op vrijdag 01 juni 2007 @ 20:33:
Een andere vraag: Op dit moment is mijn connectionstring zoals hieronder is weergegeven.

code:

con.ConnectionString = "Data Source=.\SQLEXPRESS;AttachDbFilename='C:\Documents and Settings\Jan\My Documents\Visual Studio 2005\Projects\HistoryAnalysisTool\HistoryAnalysisTool\Data.mdf';Integrated Security=True;User Instance=True"

Voor de uiteindelijke applicatie wil ik echter de connectionstring zo schrijven dat deze de opgegeven database in dezelfde directory als de uiteindelijke exe pakt. Bijvoorbeeld zoiets:

code:

con.ConnectionString = "Data Source=.\SQLEXPRESS;AttachDbFilename='<currentfolder>\Data.mdf';Integrated Security=True;User Instance=True"

Ik weet alleen niet hoe ik dit moet schrijven.

[Annie]

Probeer het eens met Application.StartupPath

[Verwijderd]

Ik weet dat het offtopic is maar waarom is cascade niet aan te raden..??
Dit is toch de manier om geen zwevende records in je DB te krijgen...en anders moet je hem gewoon naar null setten......maar als ik zegmaar een tabel heb met partners en een tabel met partner adressen en een FK naar partner dan gaat deze zeker op cascade....want waarom wil ik een adres van een partner die niet meer in mijn systeem bestaat?? of heb ik het weer niet begrepen ;LOL

[Annie]

Daarvoor heb je in een rdbms foreign key constraints. Daarbij is het niet mogelijk om 'zwevende' gegevens te krijgen. Je kan dan immers geen partner verwijderen als er nog een adres aanwezig is.