Bugs in Text Importer

[TenGor]

Hy,

i found the following Bugs in using the Text Importer:

• Import to Script
  If i had to Import a csv with 256 columns this function creates a sql-script which has rows with more than 2500 characters.
  In SQL+ i can't run these scripts, which i have to do for our customers. Perhaps there can be an option to make CR LF after f.e. 200 characters.
  
• Configuration in Text Importer
  I had the above mentioned csv with 256 columns. It is separated with ";". So i configure the 1st Field to the Seperator and want to set the Fieldcount to 256. If i do so (clear the field and write 2 into it) PL/SQL Dev adds a "0" so i had 20 Fields (all with the correct Seperator setting).
  If add an additional "0" (to have 200 Fields) PL/SQL Dev resets the complete Seperator setting to "(+0 .. +0)". So i have to do the Seperator setting for each Field again, or i use the Arrow-Buttons beside the Fieldcount 200 times...

Btw. Sometimes (can't reproduce it the easy way) if i write a text in a PL/SQL Dev Field like Owner/Tablename (when i create a table) there is a cruel behaviour:
After writing the first character PL/SQL Dev jumps back to the first position of the field. f.e. if you want to name your table "TEST" you will see "ESTT".

 

[Marco Kalter]

If i had to Import a csv with 256 columns this function creates a sql-script which has rows with more than 2500 characters.
In SQL+ i can't run these scripts, which i have to do for our customers. Perhaps there can be an option to make CR LF after f.e. 200 characters.

We'll enhance this so that it remains SQL*Plus compatible.

I had the above mentioned csv with 256 columns. It is separated with ";". So i configure the 1st Field to the Seperator and want to set the Fieldcount to 256. If i do so (clear the field and write 2 into it) PL/SQL Dev adds a "0" so i had 20 Fields (all with the correct Seperator setting).
If add an additional "0" (to have 200 Fields) PL/SQL Dev resets the complete Seperator setting to "(+0 .. +0)". So i have to do the Seperator setting for each Field again, or i use the Arrow-Buttons beside the Fieldcount 200 times...

Strange. We'll check it out.

Btw. Sometimes (can't reproduce it the easy way) if i write a text in a PL/SQL Dev Field like Owner/Tablename (when i create a table) there is a cruel behaviour:
After writing the first character PL/SQL Dev jumps back to the first position of the field. f.e. if you want to name your table "TEST" you will see "ESTT".

This is fixed in the next release.

 

[TenGor]

Hy Marco,

1st and 3rd Point sounds good. Thanks.

I'm looking forward to read the solution of the 2nd Point.

 

[TenGor]

Hy again,

while using the Text Importer i hit some other problems:

• Mismatch in Character set when i use "Import to Script"
  When i import data and create a new table or use a existing table and use the Button "Import to Script" anything is alright.
  But if i don't create a new table and use the Button "Import to Script", the script is created. However there is a mismatch in Character set.
  We have german data with

 

[Marco Kalter]

That looks like Unicode. Are all characters from the dataset supported by your Windows character set?

 

[TenGor]

How can i check this?

 

[Marco Kalter]

Open the file in notepad, and check if the text is okay.

 

[TenGor]

In Windows notepad anything is alright.
The "problem" is my viewer. It show by default "only text" and so i have the wrong character set. If i switch the viewer to UTF-8 mode anything is alright.

Are there some solutions / suggestions for the other 2 points?

 

[Marco Kalter]

I have added the 2 other problems to the list of enhancement requests.

 

[TenGor]

Hy,

an additional info for the 1st problem:

If i try to run the created script with the SQL+ from Forms 6i (8.0.6.0.0), i run into the following error: "ORA-00911: invalid character".
If i try this with the DB-SQL+ from a 10g (10.2.0.1.0) i got the error "ORA-00904: "STRA

 

[Marco Kalter]

I would have expected that the "Unicode enabled" option would control the Text Importer output as well. We'll check it out.