stanl
asked on
Failure of INSERT INTO...
I wrote a simple script using the Jet 4.0 Provider to assist in removing duplicates from a standard ASCII file, while keepng the original line number intact ( hence I could not use a DISTINCT clause ). The SQL statements follow:
; import the text file
'SELECT * INTO [line] FROM [input.txt] IN "" [TEXT;DATABASE=c:\temp]'
;add a line counter
'ALTER TABLE line ADD linecount COUNTER'
;create a temp table with a constraint
"CREATE TABLE temp (line TEXT (50),linecount COUNTER );"
'CREATE UNIQUE INDEX temp ON temp (line)'
'INSERT INTO temp (line,linecount) SELECT * FROM line;'
"SELECT line INTO [Text;DATABASE=c:\temp].[o
I get no errors, but both the output file and temp table are blank.
If I open Access, create a query and type in the INSERT statment above, it work fine, but Access forces you to confirm 2 warning screens saying it cannot apend all records.
I was wondering if this could be part of the problem and perhaps I need to add something to the script to turn the warnings off.
stan
; import the text file
'SELECT * INTO [line] FROM [input.txt] IN "" [TEXT;DATABASE=c:\temp]'
;add a line counter
'ALTER TABLE line ADD linecount COUNTER'
;create a temp table with a constraint
"CREATE TABLE temp (line TEXT (50),linecount COUNTER );"
'CREATE UNIQUE INDEX temp ON temp (line)'
'INSERT INTO temp (line,linecount) SELECT * FROM line;'
"SELECT line INTO [Text;DATABASE=c:\temp].[o
I get no errors, but both the output file and temp table are blank.
If I open Access, create a query and type in the INSERT statment above, it work fine, but Access forces you to confirm 2 warning screens saying it cannot apend all records.
I was wondering if this could be part of the problem and perhaps I need to add something to the script to turn the warnings off.
stan
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
As it turned out, if I changed my original OLE Object from the Jet OLEDB Provider to Access.Application the script worked fine. Since the DoCmd is not part of the Provider Object, that got me thinking about making that change ( but there was never a need to even touch the SetWarnings property.
I agree about holding the duplicates, but the text files are created by 'cut-and-paste' which is subject to slight error.
I agree about holding the duplicates, but the text files are created by 'cut-and-paste' which is subject to slight error.
Why are you using a script?
You can define a linked table in access to your textfile and issue all needed queries on that linked table.
Removing duplicates could be done by a GroupBy query to select the first line of each unique value and followed by a delete of the non-matching.
Nic;o)