Skip to Content.
Sympa Menu

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

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: sajeesh_kumar AT sifycorp.com
  • To: freetds AT lists.ibiblio.org
  • Subject: [freetds] Re: FreeTDS Digest, Vol 15, Issue 25
  • Date: Tue, 20 Apr 2004 14:55:10 +0500 (IST)

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 :
> https://lists.ibiblio.org/sympa/arc/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
> ***************************************
>




  • [freetds] Re: FreeTDS Digest, Vol 15, Issue 25, sajeesh_kumar, 04/20/2004

Archive powered by MHonArc 2.6.24.

Top of Page