Hi,

I'm having trouble importing CSV files using the Unicode EDBManager.

The csv files imported just fine using the non-unicode version.
Do I need to save them as UTF or should the EDBManager read standard CSV files.

What's happening is that it starts importing and the progressbar jumps 10-15% and then there is nothing, except for the server using 50% of the
CPU.  I then have to kill both the server and manager.

What can I do?

Is there a way to import a table from the non-unicode version or any other tool that you can recommend?
If only the Database Workbench had a ElevateDB module

Jan-Erik

Jan-Erik,

<< I'm having trouble importing CSV files using the Unicode EDBManager.

The csv files imported just fine using the non-unicode version.
Do I need to save them as UTF or should the EDBManager read standard CSV
files. >>

The CSV files need to be in Unicode format, but currently EDB doesn't handle
the Unicode text files that Notepad, etc. generate, which have a BOM (byte
order mark) header at the beginning.  EDB expects them to be completely
"pure" like the ANSI CSV files, except using Unicode instead.  IOW, no BOM
at the beginning.

<< Is there a way to import a table from the non-unicode version or any
other tool that you can recommend? If only the Database Workbench had a
ElevateDB module >>

No, not currently.  The issue is that the external modules must match the
calling application's ANSI/Unicode compilation, so that you cannot mix and
match the two.  I'm still trying to figure out how to work around this
issue, but haven't come up with anything yet.  I may have to add a function
call to the external modules that allows the calling application to request
a ANSI/Unicode for the interface, but that will have to wait until EDB 2.0.

--
Tim Young
Elevate Software
www.elevatesoft.com

Thanks Tim,

I used ClearEdit to save as UTF-16 Little Endian without the BOM and it imported most of records from the first file but then there was an error
message.  #9034 Error importing file.
(The importfile is truncated or incomplete)

I also tried using SuperEdi (UTF-16) with the same result.

What puzzled me was that several small files had this problem but some larger files imported just fine. (>100MB)

Well, as long as I'm getting some data in, I'm happy.

Jan-Erik

Jan-Erik,

<< I used ClearEdit to save as UTF-16 Little Endian without the BOM and it
imported most of records from the first file but then there was an error
message.  #9034 Error importing file.  (The importfile is truncated or
incomplete) >>

Could you send me the file that you're trying to import along with a CREATE
TABLE statement for the target table ?  I'll try it here and see what I can
find out.

--
Tim Young
Elevate Software
www.elevatesoft.com

Jan-Erik,

BTW, you can use the ElevateDB Manager to generate the CREATE TABLE
statement:

Right-click on the database name and then select Reverse-Engineer
Database..Generate as Generic Script..OK

Then just copy and paste the desired CREATE TABLE statement.

--
Tim Young
Elevate Software
www.elevatesoft.com

<<<
"Tim Young [Elevate Software]" wrote:

Jan-Erik,

BTW, you can use the ElevateDB Manager to generate the CREATE TABLE
statement:

Right-click on the database name and then select Reverse-Engineer
Database..Generate as Generic Script..OK

Then just copy and paste the desired CREATE TABLE statement.
>>>

Tim,

I used the Reverse-Engineer script moving the database from ANSI to Unicode, very nice!

I'll email you the necessary table script and csv file later today so you can have a look at it.
When I looked at the file I didn't notice anything out of place but I expect you have ways to find out more.

Jan-Erik

"Tim Young [Elevate Software]" wrote:

<< Is there a way to import a table from the non-unicode version or any
other tool that you can recommend? If only the Database Workbench had a
ElevateDB module >>

No, not currently.  The issue is that the external modules must match the
calling application's ANSI/Unicode compilation, so that you cannot mix and
match the two.  I'm still trying to figure out how to work around this
issue, but haven't come up with anything yet.  I may have to add a function
call to the external modules that allows the calling application to request
a ANSI/Unicode for the interface, but that will have to wait until EDB 2.0.

Tim,

This sounds like a good idea.
I hope you can find a way for V2.

BTW, I sent you an email with the necessary files for the issue where the import stops short of the EOF.

--
Jan-Erik