Gustav Brock
Gustav at cactus.dk
Mon Apr 23 04:15:50 CDT 2007
Hi John I think that wizards are mostly for one-time or simple repeated tasks. However, do you remember my observation from last year: <quote> >> 2006-05-05 20:59 Subject: MySQL insert records When inserting records by a pass-through query from Access, I've found that reading the records off a text file using LOAD DATA INFILE '../data/test.txt' INTO TABLE tempload into an empty non-indexed table runs at about 50,000 records per second even using very modest hardware. This is way faster than any normal "Insert Into ... " I've tried. However, it's a bit clumsy first to have to write the data to a file. Any comments or suggestions? </quote> You should be able to do so if not from T-SQL then from Access, and then run a modifiable import and append query in SQL Server which reads the data from the MySQL table and appends them to the internal SQL Server table. But - as you have already done the mechanics for converting the fixed length records files to csv files - that route may be faster for you; at least it is proven. /gustav >>> jwcolby at colbyconsulting.com 23-04-2007 05:56 >>> I saved an import spec from the import wizard in SQL Server 2005. I now need to use that import spec in VB.Net, but I need to modify it. I need to change the source file, make it an append instead of a make table / append, and I need to modify the datatype from NVarchar to varchar. Of course I can simply go back in to SQL Server and run the import wizard again, however this is a fixed width file which means recreating all of the field name / field width info a second time. Is it possible to just do these mods on the existing import spec or should I just bite the bullet and rebuild. I have ~ sixty more files to import into the table and I really don't want to do this 60 times. The last time I did this I actually built an Access app to create .csv files from the original fixed width files. It seems like the long way around the barn but then again I do not see how this wizard is really very useful in this case. Anyone? John W. Colby Colby Consulting www.ColbyConsulting.com