I can run a .sql file successfully in editor, however, when I add it to an import I get the following:
11/9/2011 11:41:06 AM: Reading from file AveragesNewSTT.sql
11/9/2011 11:41:06 AM: Warning: File AveragesNewSTT.sql’s encoding ‘System.Text.SBCSCodePageEncoding’ does not match the first file encoding ‘System.Text.UnicodeEncoding’. Import may fail.
What exactly is causing this error?
This is a false alarm so you can ignore it. The check should only be fired when you import data from text-based files. We need to update our code to bypass it when importing data from a query file.
This is maybe confusing:
I was able to successfully run my .tim only after I deleted the table I was appending to. Originally this table was created manually from the results tab of a query, two fields were created as varchar(255). I altered the table so these were varchar(9)/varchar(7) and setup my import wizard. This is when my data failed to import, as a result yesterday I deleted the original table, modified the import wizard to recreate the table and these fields were created as varchar(50). Without modifying the table, I updated the import wizard to insert into the existing table and it appeared to run fine.
I would assume at this point that it was a conversion error causing the .tim to fail, however, I have another process where I altered a different table and set up the import wizard and it works fine with varchar(9)/varchar(7).
So now my question is: When exporting from the results tab to a local storage table, why are fields created varchar(255) when the same fields using the import wizard are varchar(50)? If I alter to the table will the import wizard fail due to the differences in field length? What is the correct syntax to change the field length in .sql for local storage databases?
The import code of TDA is more advanced than the new export to local storage. When importing data to a new table the Import Wizard does a preveiw of the data and determines the best datatype and size. Local Storage does not have this feature yet.
I have entered this as enhancement request as CR92333. I doubt that it will make the TDA 3.1 release as it is a large piece of coding. But for sure we need this for TDA 3.5.
Debbie