[freetds] Re: FreeTDS Digest, Vol 15, Issue 25

sajeesh_kumar at sifycorp.com sajeesh_kumar at sifycorp.com
Tue Apr 20 05:55:10 EDT 2004


Hi,

My sincere thanks to freddy77. I am able to solve my problem.

Thanks and regards
Sajeesh Kumar

Quoting  freetds-request at lists.ibiblio.org:

> Send FreeTDS mailing list submissions to
> 	freetds at lists.ibiblio.org
> 
> To subscribe or unsubscribe via the World Wide Web, visit
> 	http://lists.ibiblio.org/mailman/listinfo/freetds
> or, via email, send a message with subject or body 'help' to
> 	freetds-request at lists.ibiblio.org
> 
> You can reach the person managing the list at
> 	freetds-owner at lists.ibiblio.org
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of FreeTDS digest..."
> 
> 
> Today's Topics:
> 
>    1. RE: odbc problem obtaining column name (Roger Reynolds)
>    2. Accessing Ms SQL Server queries through FREETDS C Apis
>       (sajeesh_kumar at sifycorp.com)
>    3. RE: odbc problem obtaining column name (ZIGLIO, Frediano, VF-IT)
>    4. RE: Accessing Ms SQL Server queries through FREETDS C Apis
>       (ZIGLIO, Frediano, VF-IT)
>    5. Problems with IF in queries (Guille -bisho-)
>    6. RE: More on using FreeTDS on a server (was Re: [freetds]
>       Server	dumpscore...) (ZIGLIO, Frediano, VF-IT)
>    7. RE: odbc unit test failure - earlybind (ZIGLIO, Frediano, VF-IT)
>    8. Re: odbc problem obtaining column name (James K. Lowden)
> 
> 
> ----------------------------------------------------------------------
> 
> Message: 1
> Date: Mon, 19 Apr 2004 18:30:29 +1000
> From: Roger Reynolds <rogerr at softix.com>
> Subject: RE: [freetds] odbc problem obtaining column name
> To: "'FreeTDS Development Group'" <freetds at lists.ibiblio.org>
> Message-ID:
> 	<52CC50104C44CA42835CA6D3851BD0495C32CE at sr-syd2k-ex03.syd.ticketek.com.au>
> 	
> Content-Type: text/plain;	charset="iso-8859-1"
> 
> 
> >From an ODBC application, given a query like this
>    "select user"
> where the column selected is not a real column, but
> a "psuedo column" or whatever the right term is...
> 
> I'm trying to use SQLColAttribute to obtain the "column name"
> which I believe should be "USER".
> 
> I've tried the SQL_COLUMN_NAME, as in
> 	SQLColAttribute ( stmtHandle, 1, SQL_COLUMN_NAME,
> 			 colname, sizeof(colname),
> 			 NULL, NULL);
> 
> which succeeds, but returns an empty string in colname.
> 
> If I modify the query to 
>    "select user as user"
> 
> then I get the column name defined as I expect.
> 
> 
> Bug or Feature?
> 
> Thanks
> 
> 
> 
> ------------------------------
> 
> Message: 2
> Date: Mon, 19 Apr 2004 15:25:36 +0600 (IST)
> From: sajeesh_kumar at sifycorp.com
> Subject: [freetds] Accessing Ms SQL Server queries through FREETDS C
> 	Apis
> To: freetds at lists.ibiblio.org
> Message-ID: <1082368536.4083a218dbbc7 at SifyCorp.com>
> Content-Type: text/plain; charset="iso-8859-1"
> 
> Hi,
> 
> I have written a C program using FreeTDS apis to access MS SQL Server. I
> am able
> to connect to SQL Server using C apis. But my problem is that I am not
> able to
> fetch the proper results for the queries I had sent through C program. I
> will
> give my sample code which can be great help. Pls help me.
> 
> I am sending my sample code as attachment in this mail.
> 
> One Note : I am not using any ODBC apis in this program. I am using only
> freetds
> apis only
> 
> Thanks and regards
> Sajeesh Kumar
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: tdsnew.c
> Type: application/octet-stream
> Size: 3392 bytes
> Desc: not available
> Url :
> http://lists.ibiblio.org/pipermail/freetds/attachments/20040419/d7879988/tdsnew-0001.obj
> 
> ------------------------------
> 
> Message: 3
> Date: Mon, 19 Apr 2004 13:07:44 +0200
> From: "ZIGLIO, Frediano, VF-IT" <Frediano.Ziglio at vodafone.com>
> Subject: RE: [freetds] odbc problem obtaining column name
> To: "FreeTDS Development Group" <freetds at lists.ibiblio.org>
> Message-ID:
> 	<F7F148C986A2A84F930FEB8C3B169EA025043B at OPDMEXO01.omnitel.it>
> Content-Type: text/plain;	charset="us-ascii"
> 
> > 
> > >From an ODBC application, given a query like this
> >    "select user"
> > where the column selected is not a real column, but
> > a "psuedo column" or whatever the right term is...
> > 
> > I'm trying to use SQLColAttribute to obtain the "column name"
> > which I believe should be "USER".
> > 
> 
> No, user it's like a function, you haven't a column name.
> 
> > I've tried the SQL_COLUMN_NAME, as in
> > 	SQLColAttribute ( stmtHandle, 1, SQL_COLUMN_NAME,
> > 			 colname, sizeof(colname),
> > 			 NULL, NULL);
> > 
> > which succeeds, but returns an empty string in colname.
> > 
> > If I modify the query to 
> >    "select user as user"
> > 
> > then I get the column name defined as I expect.
> > 
> > 
> > Bug or Feature?
> > 
> > Thanks
> > 
> 
> Feature :)
> 
> freddy77
> 
> 
> ------------------------------
> 
> Message: 4
> Date: Mon, 19 Apr 2004 13:21:46 +0200
> From: "ZIGLIO, Frediano, VF-IT" <Frediano.Ziglio at vodafone.com>
> Subject: RE: [freetds] Accessing Ms SQL Server queries through FREETDS
> 	C Apis
> To: "FreeTDS Development Group" <freetds at lists.ibiblio.org>
> Message-ID:
> 	<F7F148C986A2A84F930FEB8C3B169EA025C5E4 at OPDMEXO01.omnitel.it>
> Content-Type: text/plain;	charset="us-ascii"
> 
> > 
> > Hi,
> > 
> > I have written a C program using FreeTDS apis to access MS 
> > SQL Server. I am able
> > to connect to SQL Server using C apis. But my problem is that 
> > I am not able to
> > fetch the proper results for the queries I had sent through C 
> > program. I will
> > give my sample code which can be great help. Pls help me.
> > 
> > I am sending my sample code as attachment in this mail.
> > 
> > One Note : I am not using any ODBC apis in this program. I am 
> > using only freetds
> > apis only
> > 
> > Thanks and regards
> > Sajeesh Kumar
> > 
> 
> We never recommend the use of libTDS API (we always suggest one library
> between dblib/ctlib/obdc). libTDS is subject to change without any
> notice.
> 
> 	printf("Its Regular Rown");
> 	result = tds->curr_resinfo;
> 	if(result == NULL)
>         	printf("No Resultsn");
> 	buff = tds_alloc_row(result);
> 
> libTDS allocate buffer for you :)
> 
> 	printf ("No of coloumns = %dn", result->num_cols);
> 	rowcol = *(result->columns);
> 	printf("Column Size = %dn", rowcol->column_size);
> 	if(result->current_row == NULL)
>         	printf("No contents in the rown");
> 	printf("Size of the row = %dn", result->row_size);
> 	tds_clr_null(result->current_row, 1);
> 	buff = (char *) calloc(rowcol->column_cur_size + 1,
> sizeof(char));
> 	column_data = tds_get_char_data(tds, buff,
> rowcol->column_cur_size + 1, *(result->columns));
> 	tds_clr_null(buff, 1);
> 
> no, you should just read data from buffer.
> 
> 	if(column_data == 0)
> 	{
> 		printf("No Data availablen");
> 		break;
> 	}
> 	printf("The buffer = %sn",buff);
> 
> see src/tds/unittests/t0002.c for an example on how to read data.
> 
> freddy77
> 
> 
> ------------------------------
> 
> Message: 5
> Date: Mon, 19 Apr 2004 13:45:09 +0200
> From: Guille -bisho- <bisho at eurielec.etsit.upm.es>
> Subject: [freetds] Problems with IF in queries
> To: FreeTDS Development Group <freetds at lists.ibiblio.org>
> Message-ID: <20040419114509.GA4385 at eurielec.etsit.upm.es>
> Content-Type: text/plain; charset=iso-8859-1
> 
> I have a problem with queries using IF's:
> 
> -------------
> $rs=mssql_query('select 1',$connection);
> var_dump($rs);
> 
> This prints:
> resource(7) of type (sybase-ct result)
> 
> -------------
> $rs=mssql_query('if (EXISTS (select 1)) select 2 else select
> 0',$connection);
> var_dump($rs);
> 
> This prints:
> bool(true)
> 
> The most strange thing is that it works with an older version of
> Freetds.
> 
> In debian I have one machine with php-sybase and freetds0 (freetds
> 0.53-7)
> and all this queries work well (They return a valid result resource and
> the
> data can be retrieved).
> 
> The other, more updated, has libct1 (freetds 0.61-5) and returns a
> boolean "true" if the query contains if's sentences.
> 
> The problem is that freetds0 is deprecated, and no more present in
> debian.
> 
> Anybody has found this?
> 
> -- 
>         .,,,   Guillermo Pérez    -=] 19/04/2004 [=-
>       _' .,,,,  - bisho@ ( onirica.com | eurielec.etsit.upm.es )
>      (v)/ ,''
>       ( /    ::               Say NO!!! to SW PATENTS               
> ::
> bisho! ``\  ::           EuropeSwPatentFree Demostration:           
> ::
>    .........::                 http://online-demo.org                
> ::
> 
> 
> ------------------------------
> 
> Message: 6
> Date: Mon, 19 Apr 2004 14:06:39 +0200
> From: "ZIGLIO, Frediano, VF-IT" <Frediano.Ziglio at vodafone.com>
> Subject: RE: More on using FreeTDS on a server (was Re: [freetds]
> 	Server	dumpscore...)
> To: "FreeTDS Development Group" <freetds at lists.ibiblio.org>
> Message-ID:
> 	<F7F148C986A2A84F930FEB8C3B169EA025C5E5 at OPDMEXO01.omnitel.it>
> Content-Type: text/plain;	charset="us-ascii"
> 
> > 
> > Here's the latest on my efforts to use FreeTDS for 
> > server-side networking.
> > 
> > First the bad news: Microsoft's ODBC driver for SQL Server 
> > still refuses
> > to talk to my little server.  All I get is a generic 
> > "Protocol error in
> > TDS stream".  I suspect I'm failing to send some critical token in
> the
> > login response, but it's hard to be sure with an error 
> > message that vague.
> > 
> 
> I don't know too... never tried.
> 
> > Now a little the good news: I can now use the tsql program to submit
> > queries, and get tables back.  The tables don't look quite right --
> > strings come across okay, but numbers are mangled.  But I'm
> definitely
> > making progress.
> > 
> > And the real purpose of this message: Questions!
> > 
> > * Can anybody recommend an alternative ODBC/TDS driver for 
> > Windows?  One
> >   that, maybe, would give better error messages?  Or it would 
> > also be okay
> >   if it simply worked, I suppose.
> > 
> 
> As James said ODBC compile under windows. Also you can enable logging.
> 
> > * I have a log, produced by FreeTDS, of the network traffic 
> > in my failed
> >   attempts to access my little SQL server via Microsoft's ODBC
> driver.
> >   Does anybody out there have a similar dump of a *successful* login?
> >   Nothing fancy, just a TDS4.2 login such as the "test connection"
> >   button in the ODBC Microsoft SQL Server Setup dialog.
> > 
> 
> It would be useful if you zip&mail the log..
> 
> > * What should I do about queries that don't result in tables? 
> >  For example,
> >   tsql sends a "set textsize 64512" request.  My server currently
> just
> >   sends token #253 (Result Set Done).  Is that proper?
> > 
> 
> Yes and not. Any query end with a DONE token however if you issue a
> batch of 3 select you get 3 done, if you issue a batch with 3 "set
> textsize" you get only one DONE.
> 
> > * Are there any common "gotchas" when sending numbers?  It 
> > kind of looks
> >   like tsql is printing the addresses of the numbers, instead of the
> >   numbers themselves -- the values are all similar, but never 
> > identical.
> >   I don't think it's an endian thing.
> > 
> 
> If similar they can't be a endian problem...
> 
> > * Can anybody spot any obvious problems with my table-sending 
> > function,
> >   below?  The XXXX_t names are all types; their purpose 
> > should be pretty
> >   obvious, except that rows are represented as an array of 
> > value_t values.
> >   value_t is a union of all supported data types.  For 
> > strings, it is a
> >   (char *) and the actual text of the string is appended to 
> > each row's 
> >   value_t array; that way, when the row is freed so are all 
> > of its strings.
> >   Column types, names, etc. are stored in the table->col 
> > array.  By looking
> >   at the log file, I have verified that my little SQL server is
> indeed
> >   sending garbage for integers; this isn't a bug in tsql.
> > 
> > /* send a table to the client */
> > void tdsprinttable(table)
> > 	table_t table;	/* the table to send */
> > {
> > 	TDSRESULTINFO	*resinfo;/* FreeTDS library version of table */
> > 	int		r, c;	/* row & column counters */
> > 	int		rowsize;/* maximum row memory needed */
> > 	int		offset;	/* offset of field within row */
> > 
> > 	/* allocate a FreeTDS table */
> > 	resinfo = tds_alloc_results(table->ncols);
> > 
> > 	/* fill in the column info for all columns */
> > 	rowsize = 0;
> > 	for (c = 0; c < table->ncols; c++)
> > 	{
> > 		/* fill in this column's info */
> > 		switch (table->col[c].type)
> > 		{
> > 		  case OP_STRING:
> > 			resinfo->columns[c]->column_type = SYBCHAR;
> > 			resinfo->columns[c]->column_size = 
> > table->col[c].width;
> > 			break;
> > 			
> 
> you should use tds_set_column_type
> 
> > 		  case OP_INTEGER:
> > 			resinfo->columns[c]->column_type = SYBINT4;
> > 			resinfo->columns[c]->column_size = sizeof(long);
> > 			break;
> > 
> > 		  case OP_NUMERIC:
> > 			resinfo->columns[c]->column_type = SYBFLT8;
> > 			resinfo->columns[c]->column_size = 
> > sizeof(double);
> > 			break;
> > 
> > 		  case OP_BOOLEAN:
> > 			resinfo->columns[c]->column_type = SYBBIT;
> > 			resinfo->columns[c]->column_size = 1;
> > 			break;
> > 		}
> > 		strcpy(resinfo->columns[c]->column_name,
> > 				textnametext(table->col[c].name));
> > 		resinfo->columns[c]->column_namelen =
> > 				
> > strlen(resinfo->columns[c]->column_name);
> > 
> > 		/* for non-string data, the data offsets don't change so
> > 		 * we might as well set them here.
> > 		 */
> > 		resinfo->columns[c]->column_offset = c * 
> > sizeof(value_t);
> > 
> > 		/* add this column's row data size to rowmax */
> > 		rowsize += resinfo->columns[c]->column_size;
> 
> see tds_add_row_column_size and tds_process_col_fmt in token.c
> 
> > 	}
> > 
> > 	/* start the result, and send column info */
> > 	tds_send_result(tds, resinfo);
> > 	tds_send_174_token(tds, table->ncols);
> > 
> > 	/* for each row... */
> > 	for (r = 0; r < table->nrows; r++)
> > 	{
> > 		/* tell FreeTDS where the data is */
> > 		resinfo->current_row = (unsigned char *)&table->row[r];
> > 
> > 		/* convert the row */
> > 		for (c = 0; c < table->ncols; c++)
> > 		{
> > 			/* most fields' offsets don't change, but we do
> > 			 * need to worry about strings.
> > 			 */
> > 			if (table->col[c].type == OP_STRING)
> > 			{
> > 				resinfo->columns[c]->column_offset =
> > 					(unsigned char 
> > *)table->row[r][c].string
> > 						- resinfo->current_row;
> > 			}
> > 		}
> > 
> > 		/* send the row */
> > 		tds_send_row(tds, resinfo);
> 
> quite strange code... if I understand you don't use our row buffer but
> rewrite column_offset and current_row...
> 
> > 	}
> > 	resinfo->current_row = NULL;
> > 
> > 	/* end the table */
> > 	tds_send_253_token(tds, 16, table->nrows);
> > 	tds_flush_packet(tds);
> > 
> > 	/* clean up */
> > 	tds_free_results(resinfo);
> > 	didresult = 1;
> > }
> > 
> 
> Why don't you join to FreeTDS group to improve our (rudimental and not
> working) server ??
> 
> freddy77
> 
> 
> ------------------------------
> 
> Message: 7
> Date: Mon, 19 Apr 2004 14:22:35 +0200
> From: "ZIGLIO, Frediano, VF-IT" <Frediano.Ziglio at vodafone.com>
> Subject: RE: [freetds] odbc unit test failure - earlybind
> To: "FreeTDS Development Group" <freetds at lists.ibiblio.org>
> Message-ID:
> 	<F7F148C986A2A84F930FEB8C3B169EA025043F at OPDMEXO01.omnitel.it>
> Content-Type: text/plain;	charset="us-ascii"
> 
> > 
> > Hi, I am seeing a failure in the earlybind test program.
> > The code does this:
> > 
> >  	SQLBindCol(Statement, 1, SQL_C_SLONG, &id, sizeof(SQLINTEGER),
> > &ind1);
> > 	SQLBindCol(Statement, 2, SQL_C_CHAR, name, sizeof(name), &ind2);
> > 
> > However, the first SQLBindCol is failing, because SQL_C_SLONG is not
> > supported by SQLBindCol in the conditional TDS_NO_DM section.
> > 
> > This causes both earlybind and transaction tests to fail.
> > By adding SQL_C_SLONG to that switch, both tests work.
> > 
> > Is using freetds with odbc and no driver manager generally
> > tested and used? 
> > 
> > I think that is how I want to use freetds for my purposes, 
> > where I don't require driver manager features and want a really 
> > simple deployment/configuration scheme.
> > (I can easily compose the appropriate connection string 
> > programatically,
> > and I have just the one odbc driver to worry about and am 
> > happy to link
> > it at compile time rather than dynamically at run time)
> > 
> > I'll appreciate your thoughts on this...
> > 
> > Thanks
> > 
> > roger
> 
> Fixed on CVS.
> 
> Used odbc_set_concise_c_type results instead of case (so check is made
> even on normal configurations)
> 
> freddy77
> 
> 
> ------------------------------
> 
> Message: 8
> Date: Mon, 19 Apr 2004 10:26:02 -0400
> From: "James K. Lowden" <jklowden at schemamania.org>
> Subject: Re: [freetds] odbc problem obtaining column name
> To: FreeTDS Development Group <freetds at lists.ibiblio.org>
> Message-ID: <20040419102602.288c354c.jklowden at schemamania.org>
> Content-Type: text/plain; charset=US-ASCII
> 
> On Mon, 19 Apr 2004, Roger Reynolds <rogerr at softix.com> wrote:
> > 
> > From an ODBC application, given a query like this
> >    "select user"
> > where the column selected is not a real column, but
> > a "psuedo column" or whatever the right term is...
> ...
> > If I modify the query to 
> >    "select user as user"
> > 
> > then I get the column name defined as I expect.
> 
> I'd need to know precisely what your "psuedo column" is to give you a
> precise answer, because "select user" isn't parseable T-SQL.  
> 
> Tables and views have columns with names.  Queries and stored
> procedures
> can derive columns that have no names, as with functions.  
> 
> If you say:
> 
> 	select @@servername
> 	select user_name()
> 	select count(*) from systypes
> 	select 'horseradish'
> 
> in each case you'll get a column without a name.  
> 
> Whether or not a column has a name, you can create your own by tacking
> on
> "as myname" after the element.  
> 
> HTH.  
> 
> --jkl
> 
> 
> ------------------------------
> 
> _______________________________________________
> FreeTDS mailing list
> FreeTDS at lists.ibiblio.org
> http://lists.ibiblio.org/mailman/listinfo/freetds
> 
> 
> End of FreeTDS Digest, Vol 15, Issue 25
> ***************************************
> 




More information about the FreeTDS mailing list