RH 5.1 make (again)

Craig Burton craigb at ibis.com.au
Thu Oct 14 02:53:00 EDT 1999

Hi folks,

	I am keen to set up a replication checker for some SQL7.0
boxes and have been reading your mails for some time and am keen
to try freetds again...  I have gor the 047pre2, and am running
Linux RH 5.1.  I already have sybase installed etc,

	I don't get too far after make, and remember being advised
that this error was due to me having Linux 5.1.  Later, I noticed
someone had said that this had been fixed.  I did a configure
with tds as 4.2, which went fine.

	It is
cd . && aclocal
aclocal: configure.in: 14: macro `AM_PROG_LIBTOOL' not found in library
make: *** [aclocal.m4] Error 1

	hmmmm...  please let me know what else you need...

-----Original Message-----
From: bounce-freetds-92240 at franklin.oit.unc.edu
[mailto:bounce-freetds-92240 at franklin.oit.unc.edu]On Behalf Of Brian
Sent: Saturday, October 02, 1999 10:14 AM
To: TDS Development Group
Subject: [freetds] Re: CT lib source?

On Fri, 1 Oct 1999, Mark Schaal wrote:

> > Perhaps, what is needed is a tds->results_exist similar to the
> > res_info->rows_exist that is used for DBROWS()? This would allow you to
> > always know whether the previous result processing found anything or not
> > and could be cleared on a call to tds_process_row_tokens already in the
> > TDS_COMPLETED state, allowing ct_results to tell the difference without
> > the hokey 'empty_res_hack' flag I just introduced.
> > 
> > What do you think?
> > 
> > Brian
> I think tds_process_result_token() needs to be redesigned slightly, 
> but I'm not sure what are the needed/correct changes.  The current
> ct_results() hack isn't pretty.  If we need a hack I'd prefer having
> it in the TDS layer rather than the client libraries.
> One thing is that I suspect tds_process_result_token() ideally should
> return twice on an empty select query - once after the result setup
> information (col_names,col_info) and once for the end token.  Well,
> I know it returns twice now so I should say the returns should better
> reflect the actual token reads.  Currently for an empty result the end
> token is read in the first call but for a non-empty result the end token
> is read in the second call.  This complicates the logical flow, e.g.
> this means we can't free res_info on an end token since it might really
> have been a col_names+col_info+end_token instead.

Can't free res_info on an end token anyway, it is legal for the client to
check dbhasstat() dbretstat() and others after the query is completely

This is how things used to work, then something (PHP I think) needed
DBROWS() implemented. The problem is that when tds_process_result_tokens
returns the first time it needs to know whether there are rows or not,
which means it needs to read the next message. (Granted it could probably
do an unget after it reads the next token.

So the the stream must be read until 1) a row token 2) another result
token 3) an end token. Now that I'm looking at it, I want to say there was
once an tds_unget_byte() after reading an end token in the
process_result_tokens loop.  It definately doesn't look right the way it
is now.

> Of course I'm being influenced by how ctlib views things and need to
> check dblib compatability.
> Another thing is that I keep hearing this whisper in the back of my mind
> that says "what about compute results?" and that adds complications.
> For a while I was considering a tds->result_type or res_info->result_type
> which could be set to REGULAR, COMPUTE, NONE, etc., but when I ran what I
> hoped would be a simple compute query "select id from items compute
> I got something like:
> 	col_names
> 	col_info
> 	token_167	(some compute token)
> 	token_168	(compute col_info?)
> 	regular rows...
> 	compute row
> which interleaves regular and compute info which I didn't expect.  I don't
> know if anyone much uses "compute" but I'd like to at least make it easy
> for future support.
Interesting. I have some preliminary stuff in there that works for simple
computes, but by no means a complete implementation.

> Mark
> -- 
> Mark J. Schaal					Phone:      (909)
> TST On Ramp					Fax:	    (909) 620-8174
> System Administrator				E-Mail: mark at tstonramp.com

You are currently subscribed to freetds as: craigb at ibis.com.au
To unsubscribe, forward this message to

More information about the FreeTDS mailing list