xsharp.eu

Chris wrote:

robert wrote:In the team Chris is our guardian of readability.

Its all Greek to me...

So, back with 2.4 still using the same mini X#-RT app: Still compiles fine, returns ".T." but keeps the dbf empty.

I can't find in the help of AppendDelimited any mention that i would have to set to another driver, nor do i see anything in the what's new paragraphs regarding RDD to explain, why i fail...
I changed to an inherited server class to add the AppendDelimited Code from Git, to see if i could find a clue in debugging, but to no avail.

The source looks like:
kdno,adrno,nname,vname,straße,plz,ort,staat
0492,0001,Stump,Rüdiger,Im Tal 21,79136,Rickenbach,D
....
(in reality the fields are right padded with blanks for the required field length)

TIA!

Karl,
Can you mail me the DBF and text file ?
Robert

Sent

FFF wrote:The source looks like:
kdno,adrno,nname,vname,straße,plz,ort,staat
0492,0001,Stump,Rüdiger,Im Tal 21,79136,Rickenbach,D
....
(in reality the fields are right padded with blanks for the required field length)

Hi Karl,
not to the code in question, but as a general hint from the embolded part of your post:
if the source is really rightpadded to field len (which for instance is typical for adress brokers), it is MUCH safer to create an input cursor or tmp table with all as txt fields plus "comma fields" and input source as SDF file (which a dbf after Header in essence really is in any case)
and in second step select all "real" fields, CASTing val() of the numeric fields to correct data type in result cursor, thereby getting rid of all "comma0x" fields.
Even in Excel-like delimited char fields you will sooner or later run into fields where delimiter is inside the field (or separator, if not delimited) and you have import troubles - not so if importing as SDF.

Yes, results in "reading" data twice, but not a real showstopper in performance time

If source is/has to be really any kind of CSV, try to define/agree on separator/delimter totally out of normal usage: Even | and chr(7) might happen in text given as source (think table header or error notification msg), try to pick safest among control ASCII chars (below dec 32/space), perhaps out of the device control range...

If this a recurring task, both tables usually can be created via fixed routine from data dictionary description given with data from source or parsing first data row typically echoing the field names - then you are in safer SDF waters.

Been there, done that (for a couple of years...): less to worry about.
thomas

Thomas,
all valid points, much appreciated. In this case, IIRC, this is the first csv i read for > 10 years, so, no, no recurring task

Karl,
The problem seems to be that there are actually 3 delimiters involved when reading a text file like this:
1) The (optional) string delimiters around text value (missing in your case)
2) the field delimiters between the fields
3) the record delimiters (CRLF in your case)
The documentation for AppendDelimited() says that the cDelimiter parameter is "The delimiter for fields within a delimited database file. " In my implementation I had not correctly implemented this and used this delimiter for the string values (1).
If you call AppendDelimited() without this parameter then it works. However the field names on the first row are "corrupted". That happens also in VO, because the file has a Byte Order Mark in the beginning (it is UTF8). If you convert the text file to Ansi then it works.
I will see if I can detect this in the RDD system and convert the file on the fly.

Robert

Robert,
thx, that did the trick. One additional glitch: the AppendDelimited called without delim param now inserts the fieldnames as values of the first record...

Karl,
That's what VO does as well.

Robert

robert wrote:Karl,
That's what VO does as well.

Really? Never had to try... Then, pls remove this compatibility