asked on

Best way to truncate an entire database under Sql Server 2005 Express?

Hello,

I have a project that involves regularly flushing data from 3 tables with the following structures:

Customer - all the usual fields + a primary key of customer id, PKCustomerID referencing FKCustomerID in the Orders table.

Orders - basic billing/shipping info and a primary key of orderid, PK OrderID, and a foreign key of FKCustomerID referencing PKCustomerID in the customer table.

OrderItems - order line item information, primary key of PKOrderLineItemID, foreign key of FKOrderID referencing PKOrderID in the Orders table.

Essentially, this is like an intermediary database that we import new information into on a daily basis, but flush the old data first. There's an application that sits on top the SQL Server database that allows creation/deletion of databases. Right now, I'm doing I'm flushing the existing data by recreating the database with the application that sits on top the DB, since I can't just truncate each table in turn due to foreign key relations, triggers, etc. but that's rather tedious/time consuming.

Is there an easier way to just empty all records from the database in general without having to drop/recreate the foreign keys etc?

Any insight greatly appreciated.

Thanks!
-James

chapmandew

>>Is there an easier way to just empty all records from the database in general without having to drop/recreate the foreign keys etc?

No, not really. You could truncate the tables, but you'd have to drop the FKeys first.

Mark Wills

Well you can just do a delete. then wait. Can change the database to simple for a little while, then change it back - it will help a bit. But those foreign keys will prevent a truncate.

SOLUTION

Éric Moreau

membership

This solution is only available to members.

To access this solution, you must be a member of Experts Exchange.

Start Free Trial

aaronakin

It sounds like you are using these 3 tables to stage your data. In my experience, you generally do not add constraints to staging tables. Instead, you should verify and cleanse the data once it is in your staging tables and before it goes into the prod tables. This means no FKs. This also allows you an easy way to truncate the tables before you repopulate them.

Mark Wills

Could also change the foreign keys to cater for cascading deletes. Won't help with truncate, but then only have to delete "parent" table.

jmoriarty

ASKER

Scripting the DB is a great idea, I wish I'd thought of it before. What's the best way to go about that with MSSQL 2005 Express? Have to excuse my ignorance, my experience is primarily in MySQL. Cascading delete is a good option as well, that's something we could build into the import script even.

It's a little more complex than just using those tables to stage data unfortunately. We basically have a proprietary module for processing shipments that has no real "import" tool, so we export orders from our ecommerce system to import into the shipping app, but the only access we have is to the database itself, which contains all kinds of triggers, stored procedures, and the aforementioned constraints. So each day's orders are exported from the ecommerce database for import into the shipping application.

It's definitely not the best solution; Ideally I want to build an app to handle most of the data migration automatically, but there's other development projects of higher priority in the short term.

Thanks for the help folks.

jmoriarty

ASKER

I misspoke slightly in the above. I know where to generate the scripts from within MS SQL Management Studio, but the issue is, one of the tables (Users) has an encrypted password field. What option do I need to set on the script generation wizard, or what's the best way to script those type of objects?

Here's the error I'm getting:

TITLE: Microsoft.SqlServer.Express.Smo
------------------------------

Script transfer failed.

For help, click: http://go.microsoft.com/fwlink?ProdName=Microsoft+SQL+Server&ProdVer=9.00.2047.00&EvtSrc=Microsoft.SqlServer.Management.Smo.ExceptionTemplates.FailedOperationExceptionText&EvtID=Script+transfer+Transfer&LinkId=20476

------------------------------
ADDITIONAL INFORMATION:

Script failed for Server 'SQL_SERVER_BOX1'. (Microsoft.SqlServer.Express.Smo)

For help, click: http://go.microsoft.com/fwlink?ProdName=Microsoft+SQL+Server&ProdVer=9.00.2047.00&EvtSrc=Microsoft.SqlServer.Management.Smo.ExceptionTemplates.FailedOperationExceptionText&EvtID=Script+Server&LinkId=20476

------------------------------

Property TextHeader is not available for Trigger '[TG_Users_Change]'. This property may not exist for this object, or may not be retrievable due to insufficient access rights. The text is encrypted. (Microsoft.SqlServer.Express.Smo)

For help, click: http://go.microsoft.com/fwlink?ProdName=Microsoft+SQL+Server&ProdVer=9.00.2047.00&EvtSrc=Microsoft.SqlServer.Management.Smo.ExceptionTemplates.PropertyCannotBeRetrievedExceptionText&EvtID=TextHeader&LinkId=20476

------------------------------
BUTTONS:

OK
------------------------------

Alternatively, is there a way to remove the encryption from a trigger/database object? it's a local application, no need for encryption other than plain text since everyone has the credentials by default anyways.

Mark Wills

If it is just Customer, Order, Orderitems, then why do the entire database ?

Create script to create the Foreign Key constraints, and then use that to write a new script :
1) drop FK
2) truncate items, orders, customers (in that sequence)
3) create FK

ASKER CERTIFIED SOLUTION

Mark Wills

membership

This solution is only available to members.

To access this solution, you must be a member of Experts Exchange.

Start Free Trial

jmoriarty

ASKER

That's a very good point, mark_wills. I was thinking of doing the whole thing because data does exist in the other tables, and could do a blanket drop/resubmit, but this is a much better option I think. The rest of the data is static anyway. Going to give that a go in a short bit then. I shall report back.

Thanks again for the collaborative comments.

jmoriarty

ASKER

Hi Folks,

Thanks for the help so far. There were a lot more foreign key references than I was first aware of. References from other tables to these target tables basically. So I'm working through finding & adding those to the script in the short term. I'll report back on success or failure shortly.

Mark Wills

this might help:

select * from information_schema.table_constraints where constraint_type like 'F%'

jmoriarty

ASKER

That helped immensely actually. There was almost 25 keys referencing those tables that needed to be accounted for as well before they could be truncated. Got a good script working now though, in the fashion you suggested.

Thanks again!
-James