Francisco Tapia
fhtapia at gmail.com
Fri Aug 19 12:01:15 CDT 2005
The way we did it is write some DTS jobs that would truncate the Sql Server tables before the import, this afforded us the ability to import fresh data at a whim while still developing stored procedures for data access. Will the customer still be using the current FE? If so the import process ought to be a huge breeze, since you're just importing data, you would not need to write any sprocs, just perhaps views so that the end users do not hit the actual datatabales themselves. On 8/19/05, Susan Harkins <ssharkins at bellsouth.net> wrote: > > I've got an existing SQL Server database and an Access database. The > client > wants to dump the Access data into the SQL Sever database and dump the > .mdb > file completely. This is a one-time job. > > I figure I have two approaches: > > 1. We can clear a block of time to manually import the Access data. I'd be > working with a backup copy and they'd have to agree not to use the SQL > Server database while I was importing -- > 2. After reviewing the backup, I could write the necessary stored > procedures > and let them run them to import the data themselves. That way, they > wouldn't > have any downtime. > > Any comments? Any other suggestions? I don't have to convert anything > other > that Access datatypes that won't import as is -- any comments about that? > I > don't anticipate much trouble outside of maybe having to dump some dates, > but I haven't reviewed the Access data yet, so that might not be > necessary. > > Susan H. > > _______________________________________________ > dba-SQLServer mailing list > dba-SQLServer at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/dba-sqlserver > http://www.databaseadvisors.com > > -- -Francisco http://pcthis.blogspot.com |PC news with out the jargon! http://sqlthis.blogspot.com | Tsql and More...