FreeTDS Development Group

["Thompson, Bill D (London)" <ThompBil AT exchange.uk.ml.com>]

James,

You're right on all counts. I've had all the same thoughts as you.

> 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.  

Absolutely right. I was thinking about doing this.
It looks to me like the ctlib and odbc bcp implementations are structurally
very similar to the dblib one,
so it should be very easy to port them. 
In the meantime, once you've put all the bcp related stuff into its own
structure (then included into DBPROCESS),
the only source code that should need changing is bcp.c

> 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.  

yeah, bummer. I think I sorted it though, altho' its a mite untidy. take a
look at this.

It's an OLD, OLD version of bcp.c with some changes in for all this.

 <<bcp.c.gz>> 
You need to look at the function bcp_read_hostfile, and the code in
bcp_exec_in that calls it.

I implemented a little structure of flags , passed to bcp_read_hostfile,
which would indicate the status of the record, and each individual column.
Thinking about this again , it would be better done with an extra flag in
the hostcol structure. The benefits of hindsight, I suppose.

the code in bcp_read_hostfile does an ftell() on the host file before going
through each column. If an error's found it goes back and reads the whole
"row" into a field in the dbprocess, which bcp_exec_in can then write out to
the error file.

AFAICR , This code all worked, although I was less than 100% satisfied with
it aesthetically speaking.

Do with it what you will! 
Alas I have hardly enough time to think, let alone do any freetds changes!

BTW, We've linked FreeTDS to Roguewave dbtools++ !

Bill

> -----Original Message-----
> From: Lowden, James K [SMTP:LowdenJK AT bernstein.com]
> Sent: 05 November 2002 16:32
> To:   TDS Development Group
> Subject:      [freetds] RE: compile problems and warnings
> 
> > 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.
> 
> 
> 
> ---
> You are currently subscribed to freetds as: [thompbil AT exchange.uk.ml.com]
> To unsubscribe, forward this message to
> $subst('Email.Unsub')

Attachment: bcp.c.gz
Description: Binary data