Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » ElevateDB Technical Support » Support Forums » ElevateDB SQL » View Thread |
Messages 1 to 10 of 24 total |
IMPORT with QUOTE CHAR #0 |
Fri, Nov 27 2009 8:09 PM | Permanent Link |
"Malcolm" | 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 -- |
Mon, Nov 30 2009 5:23 AM | Permanent Link |
"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 -- |
Mon, Nov 30 2009 9:19 AM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | 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 |
Mon, Nov 30 2009 9:48 AM | Permanent Link |
"Malcolm" | 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 -- |
Mon, Nov 30 2009 10:36 AM | Permanent Link |
"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 |
Mon, Nov 30 2009 10:44 AM | Permanent Link |
"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 |
Mon, Nov 30 2009 5:10 PM | Permanent Link |
Richard Harding | 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 |
Mon, Nov 30 2009 6:06 PM | Permanent Link |
"Malcolm" | 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. -- |
Tue, Dec 1 2009 9:35 AM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | 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 |
Tue, Dec 1 2009 9:40 AM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@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 |
Page 1 of 3 | Next Page » | |
Jump to Page: 1 2 3 |
This web page was last updated on Tuesday, May 14, 2024 at 07:14 PM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |