Hi Tim

Did you have a nice Thanksgiving?
It has certainly been quiet in here.

However, have you tried as in the topic title?

Having finally managed to create BOMless input files I was then
frustrated by importing into a temp table and getting the expected
number of records .. but with every field being NULL.

Same result with 'normal' tables - even using files exported/imported
by the Manager.  Export is fine - only import is faulty.

But import works fine if the QUOTE CHAR is not #0.  
Is this the price I must pay for #0?  

Malcolm

--

Does anyone else see this problem?

In the Manager (unicode but ansi should be the same) I have been
doing this:

CREATE TABLE "ATableCopy"
(LIKE "ATable");

Then running a script like:

SCRIPT ()
BEGIN
  EXECUTE IMMEDIATE 'EXPORT TABLE "ATable"
                     TO "Data.csv"
                     IN STORE "AStore"
                     DELIMITER CHAR #124
                     QUOTE CHAR #34';
  EXECUTE IMMEDIATE 'IMPORT TABLE "ATableCopy"
                     FROM "Data.csv"
                     IN STORE "AStore"
                     DELIMITER CHAR #124
                     QUOTE CHAR #34';
END

This works as expected.
Now delete the records from "ATableCopy" and edit the script to
change both QUOTE CHAR #34 to #0

Execute the script again .. and I see the correct number of records
imported, but all values are NULL.

The Data.csv file looks OK using #0

Malcolm
--

Malcolm,

<< Does anyone else see this problem? >>

I'm not seeing any issues with using #0 as the delimiter character.
EXPORT/IMPORT both work fine, and all of the data is there after the IMPORT.
Same result with both ANSI and Unicode.

Are you sure that you're running the latest build ?

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim Young [Elevate Software] wrote:

> Malcolm,
>
> << Does anyone else see this problem? >>
>
> I'm not seeing any issues with using #0 as the delimiter character.
> EXPORT/IMPORT both work fine, and all of the data is there after
> the IMPORT. Same result with both ANSI and Unicode.
>
> Are you sure that you're running the latest build ?

Hi Tim

Well, I *really* hope I am not.
But given the other unexplained issue I had, I suspect something is
trashed here.

I already reverted back to build 5, then forward to 2.03b6 again.
But in the Help and .pdf manuals I see no mention of #0 and I am
fairly sure I saw that before in the Help (not the 'incidents..').

The Manager says it is 2.03b6.  I will uninstall, wipe, re-download,
etc and hope I can report back with better news.

Malcolm

--

No luck.  

Should the Help file (.chm) document the QUOTE CHAR #0?  Mine does
not!

I have uninstalled the previous 'add' stuff and deleted its folder
tree on a Vista machine which does not have the vcl installed on it.

Re-downloaded D2009 2.03 b6 (unicode) non-source.

Installed the add utilities.

Run the Manager which reports it is 2.03 b6 unicode.

I still get the records imported but with *every* column of *every*
record showing NULL in the Manager.  <Grrrrrr><sigh>

I can happily create the destination table per the example statement.
I can happily import the data generated using #34, so I think I have
all the necessary rights.

How can I be having a problem!

Malcolm

Malcolm wrote:

> Ah!  A work around!

If I generate the file using #0, but import it with #34 ..
... it works!

Hmm, insanity is only a hair's breadth away now!

Malcolm

Malcolm,

>>If I generate the file using #0, but import it with #34 .. ... it works!

Why do you need (or want) to use the NULL character as a delimiter?  This means that you
are not using a delimiter character around the string values.  You will save yourself some
grief if you use a double quote (#34), single quote (#39) or tilde (#126) as your string
delimiter.

If all you want to do is copy data from one table to another, you can use the INSERT
statement.

INSERT INTO ATableCopy
  SELECT * FROM ATable

Richard Harding

Richard Harding wrote:


> Why do you need (or want) to use the NULL character as a delimiter?
> This means that you are not using a delimiter character around the
> string values.  You will save yourself some grief if you use a
> double quote (#34), single quote (#39) or tilde (#126) as your
> string delimiter.
>
> If all you want to do is copy data from one table to another, you
> can use the INSERT statement.
>
> INSERT INTO ATableCopy
>    SELECT * FROM ATable
>
> Richard Harding

Hi Richard

I am importing data submitted over the internet in csv format.  With
no quoting of strings. <shrug>

Tim fixed it so this would work.  But something odd is going on, at
least for me.  However I do have a working solution as unquoted
string fields do seem to import OK even if another or even no QWUOTE
CHAR is specified.

I don't understand .. but my app now works.

--

Malcolm,

<< Should the Help file (.chm) document the QUOTE CHAR #0?  Mine does not!
>>

No, I had to hold off on updating the docs because we're in the middle of
revamping all of our document generation with new layouts, logos, etc.

<< How can I be having a problem! >>

I do not know.  However, if you'd like to send me the database catalog and
table files that you're using, I can give them a try here and see what the
issue is.

--
Tim Young
Elevate Software
www.elevatesoft.com

Malcolm,

Never mind - I found out what the issue is.  The export is still screwed up
a bit, and is including #0 delimiters in the output data.   A fix will be in
the next build.

--
Tim Young
Elevate Software
www.elevatesoft.com