V4RB b41, Example Advanced/ImportExport.

[Erik Mueller-Harder]

On Feb 1, 2005, at 15:49, Ruslan Zasukhin wrote:

>> 1.  How do we handle situations where our field or line delimiter
>> happens to exist in one of the string or binary fields we're 
>> exporting?
>> Hmmm.  Or, I can work around this by using guaranteed-unique field and
>> line delimiters....  Can I use Unicode "private-use" code points
>> between E000 and F8FF?
>
> this is TEXT import, so binary and BLOBs should not be used here

OK; forget binary/non-text BLOBs....

Text, String, & VarChar fields, though, often contain the very 
characters we often delimit with (CR, tab, comma, etc.).  I see that 
you've provided for user-specified delimiters (though I understand it's 
not implemented yet).

Once they're working, will we be able to use any code-point as a 
delimiter?

If so, I'll be very happy to use code points from the area I mentioned 
above (E000 to F8FF), which I understand are reserved for private, 
internal use by applications -- offering me some assurance that the 
text I'm importing or exporting won't contain the same code points.

If not, will there at least be the capability of "escaping" the text 
we're exporting (and importing!) in some way so that V4RB knows that 
field or record delimiters it finds in my text are not actually 
delimiters?

I'd much prefer the former solution, but the latter would probably work 
around the problem adequately.

>     I think only XML can handle them,
>     may be your own format.

Yes, that would work, too, of course.

I was thinking, though, that I might be able to save some work :-) -- 
and also perhaps use the *same* output for both data transaction 
logging *and* for backup database regeneration purposes.

>> 2.  This is all currently done with cursors; will it be possible to do
>> it from sets?
>
> Have not big sense. Problem is that with Tables you cannot specify 
> which
> fields to export and in which order. Cursors do this easy and 
> perfectly.

You're probably right.  So far, I've been able to do almost everything 
without resorting to SQL -- and it's made me *happy*!

I'm currently adding, modifying, and deleting table records entirely 
without SQL, and I'd hoped I'd be able easily to issue a second command 
(right after AddRecord(), say) to create a log of what had been done:

	myTable.AddRecord()
	myTable.ExportRecord(transactionLogFile, append)

>> 3.  Would it be possible to create a variation, where the data stream
>> was returned to the user in the form of a string, rather than written
>> out to a file -- or maybe give us an option to "append" rather than
>> replace a file?
>
> Append -- interesting idea.

You see why it would be useful?

> Data stream? I do not se easy way how.
> In worse case you can open file, right ?

Well, for debugging -- or potentially for on-going logging to the 
screen in some applications -- it would be very useful simply to have a 
string that contained tab- (or other character) delimited values, 
exactly as you're currently writing to an export file.  It would 
probably be most useful for single-record logging (like my example 
above), but I suppose there'd be no reason to limit it to such use.

Your import/export example excited my imagination.  It seems so close 
to what I need....

-- Erik