I don't known if allowing malformed CSV is a good idea. Where do you draw the
line with what is acceptable?
Yes, I knew it's a bad practice, but under some circumstances I have to "assume"
that the data is "always" correct. I think the first step is I have to grab all
the data first (and insert it to a real database, in my case). Then the second
step is update the "wrong" values with the correct ones after the data has been
within the database.
Also, I can't think that you can create a parser that can handle all forms of
malformed CSV at the same time...
Yes, I agree with this too. It's almost impossible to handle all kinds of
malformed CSV. That's why the behavior of the parser can be tuned according to
the what kind of malformed CSV it's going to parse.
I don't think you should treat the symptom, but rather the underlying cause
of the problem. A better approach will be to let the parser report on issues
found and let the person/company who created the CSV file know that their
CSV generator is broken and should fix it.
I have a different approach. I prefer my application able to display all the
data within the CSV, including the malformed rows. The client then can fix those
wrong data by themselves via an application. This way I'll only work once and
straight, and the rest of the works can be continued by the client. No need to
back-and-forth just for data clarification. Besides, not every my client has
someone who responsible for the CSV generation (usually they got it from ancient
buggy software which is no longer has support). But mostly have people to fix
the data (application user/operator).
-Bee-
has Bee.ography at:
http://beeography.wordpress.com
_________________________________________________________________
To unsubscribe: mail [EMAIL PROTECTED] with
"unsubscribe" as the Subject
archives at http://www.lazarus.freepascal.org/mailarchives
