FreeTDS Development Group

["Lowden, James K" <LowdenJK AT bernstein.com>]

> From: Thompson, Bill D (London) [mailto:ThompBil AT exchange.uk.ml.com]
> Sent: November 5, 2002 10:40 AM
> 
> I've worked in the past on implementing the -e flag myself, 
> but it's fallen by the wayside a little.
> I'm happy to give you some ideas/code fragments if you like...

Hi Bill,

Sure, I'm interested in your thoughts.  I'm debating with myself just how to
go about it, as a matter of fact.  

I think it might be a good idea to create a nested struct in DBPROCESS to
hold the bcp-related things, and write bcp routines in terms of that
structure.  That way, the other APIs could nest the same structure and gain
the same functionality.  I'm considering moving the file handles and state
variables into such a struct, so we don't have to pass them around.  

Reason is, there should be some single handler to say, "your data file is
bollixed on line X column Y, reason Z.", and write the information (and
input row) to the error file if it exists.  (It's probably simplest to
default the error file to /dev/null instead of NULL.)  The likely candidate
for a central handler is _bcp_err_handler(), or possibly a wrapper
"_bcp_err_file_handler()".  

Problems can occur parsing the input file or writing to the database
(null/non, data conversion).  So there are lots of points at which we may
require the error handler.  

Oh, and as far as I can tell, _bcp_read_hostfile() reads a column at a time
from the file, not a line.  So it will be a little tricky to write the whole
row to the error file.  I've never thought Sybase's error files were
especially easy to read, but it's probably a good idea to present the error
in the context of the whole row.  

Sometimes I just want to give up and write the thing in C++.  The problem
domain cries out for it.  

Regards, 

--jkl


The information contained in this transmission may contain privileged and
confidential information and is intended only for the use of the person(s)
named above.  If you are not the intended recipient, or an employee or agent
responsible for delivering this message to the intended recipient, any
review, dissemination, distribution or duplication of this communication is
strictly prohibited. If you are not the intended recipient, please contact
the sender immediately by reply e-mail and destroy all copies of the
original message. Please note that we do not accept account orders and/or
instructions by e-mail, and therefore will not be responsible for carrying
out such orders and/or instructions.