> -----Original Message----- > From: Dennis Cote [mailto:[EMAIL PROTECTED] > Sent: Monday, October 02, 2006 1:44 PM > To: sqlite-users@sqlite.org > Subject: Re: [sqlite] import syntax and null values > > > Fred Williams wrote: > > > > > > Don't mean to split hairs, but... > > > > For the following, the "," is the field delimiter and '"' > is the string > > delimiter. > > > > Although this may fly in the face of reality, an empty > string should be > > denoted with ,"", and a null value by ,,. Who is to say whether ,, > > denotes an empty string or an unknown value? ,"", > specifically denotes > > an empty (zero length) string, where ,, truly indicates an unknown > > value. > > > > With current thinking, is the ,, string zero length or unknown? > > Following current logic a numeric input value of ,, should be > > interpreted as zero (0) not a null value. An unknown value > is not equal > > to zero, here in Texas when playing Texas Hold-em! > Otherwise I would > > win every hand :-) > > > > > Fred, > > You are using two different separator characters. The current sqlite > shell does not do this, it uses a single separator string. > All the input > fields are also strings (i.e. there are no numbers until > sqlite tries to > store the string and looks at the columns affinity). It views > an input > line as a sequence of strings like this: > > line = input (separator input)* > > If you use a comma as your separator, then any quotes that are on the > line are part of the input strings, not delimiters for the > input strings. > > You are assuming that the sqlite shell works like a real CSV > reader when > it doesn't (it's not very smart). Now, if you were to fix the import > command so that it correctly handled CSV data (including commas and > quotes in quoted strings) that would also be a good enhancement to > sqlite. You should also submit a patch if you do this. > > Dennis Cote
Dennis, I must warn you I am a semi-retired "Consultant." And we all know that Consultants only recommend, they never get their hands dirty with actual work! :-) Besides, I don't consider myself on a level with the "C" programmers involved with actual support of SQLite, only grateful for their superior expertise. Bringing the command line utility up to full CSV reader specifications would greatly enhance the "industry compatibility" of SQLite and should contribute zero to the .DLL footprint. I therefore, semi Recommend that one of you "C" coder whizzes whip out the required changes and we will all be grateful. Backward compatibility could be managed with a new .command. I seldom use the command line processor and completely abandon using it for data import, because it was so limited in import functionality. Everything I have imported into SQLite to date has been the output of another database product or spreadsheet utility, and I guess I have just been lucky each exports fully compatible .CSV files. Since my old DOS/Unix days are fading from memory, along with most everything else, I have found "SQLite Administrator" to be a very capable GUI based SQLite utility, that happens to have a full featured .CSV file import and export. Fred ----------------------------------------------------------------------------- To unsubscribe, send email to [EMAIL PROTECTED] -----------------------------------------------------------------------------
