FreeTDS Development Group

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

> From: Pascal Miquet
> Sent: Friday, November 26, 2004 5:06 AM
> 
> [MSSqlServer]
>         host = 192.168.5.21
>         port = 1433
>         tds version = 7.0
>         dump file = /tmp/freetds.log
>         dump file append = yes
> 
> And to make sure to get all the activity during the connection I've
removed
> the log file before sending informations.
> 
> I've restarted all the stuff and got some funny things:

I'm still puzzled by why you don't see a normal preamble at the top of
the log.  I don't use "append = yes" very much, but if you're not
getting a complete log, I'd say we have a bug.  

> pid: 2000:10:41:01.927205 processing result tokens.  marker is
> 81(TDS7_RESULT)
> pid: 2000:tds_get_string: reading 14 from wire to give 7 to client.
> pid: 2000:10:41:01.927332 tds7_get_data_info:1451:
>       colname = loginID (7 bytes)
>       type = 56 (int)
>       server's type = 56 (int)
>       column_varint_size = 0
>       column_size = 4 (4 on server)
> pid: 2000:10:41:01.927398 processing result tokens.  marker is
d1(ROW)
> pid: 2000:odbc:SQLColAttribute: fDescType is 1
> pid: 2000:odbc:SQLColAttribute: fDescType is 2
> pid: 2000:odbc:SQLColAttribute: fDescType is 6
> pid: 2000:10:41:01.927663 processing row tokens.  marker is  d1(ROW)
> pid: 2000:10:41:01.927721 processing row.  column is 0 varint size = 0
> pid: 2000:10:41:01.927820 processing row.  column size is 4
> pid: 2000:10:41:01.927872 clearing column 0 NULL bit
> pid: 2000:convert_tds2sql: src is 56 dest = 1
> pid: 2000:convert_tds2sql: outputting character data destlen = 1
> pid: 2000:tds_submit_query(): state is PENDING
> pid: 2000:10:41:01.928469 tds_client_msg: #: "Attempt to initiate a
new
> SQL Server operation with results pending.".  Connection state is now
1.

Bill and Frediano overlooked this 20019 message.  So did you.  Is you
application correctly detecting this error condition?  

The next lines in the log are: 

> pid: 2000:SQLFreeHandle(3, 0x91f0d80)
> pid: 2000:SQLFreeHandle(3, 0x91e7790)

I wonder.  Perhaps the invalid WHERE clause stems from PHP freeing some
resource in response to the above "pending results" error?  It could be
that the logic error in your application is exposing ill behavior in PHP
(or FreeTDS).  

However, I expect that once you correct the logic -- i.e., do completely
read all results prior to issuing a new query -- the WHERE clause will
correct itself and everything will be OK.  

Regards, 

--jkl

> -----Message d'origine-----
> De : freetds-bounces AT lists.ibiblio.org
> [mailto:freetds-bounces AT lists.ibiblio.org]De la part de James K.
Lowden
> Envoye : vendredi 26 novembre 2004 06:51
> A : FreeTDS Development Group
> Objet : Re: [freetds] Inserting data into tables[Ce message a ete
> verifie]
> 
> 
> "Pascal Miquet" <p.miquet AT hafiba.fr> wrote:
> > Sorry, but this is the only things I got into the freeTDS log.
> > Is there any options to activate ?
> 
> Oh, I see.  I'm sorry too, then.  I thought you sent a small portion
of
> the log to preserve your data's privacy.
> 
> I think you probably want to set "dump file append = yes" in
freetds.conf.
>  Otherwise, each *connection* to the database re-opens the log file.
On a
> web server in particular, this causes a lot of information to be lost
as
> concurrent sessions overwrite the log.  (It's something we'd like to
fix,
> but haven't yet.)
> 
> A good log will begin something like:
> 
>       Starting log file for FreeTDS 0.63.dev.20040430
>         on 2004-05-01 13:31:41 with debug level 99.
> 
> Beware that the above setting will make your log grow indefinitely.
> 
> HTH.
> 
> --jkl
> 
> > -----Message d'origine-----
> > De : freetds-bounces AT lists.ibiblio.org
> > [mailto:freetds-bounces AT lists.ibiblio.org]De la part de Lowden,
James K
> > Envoye : mercredi 24 novembre 2004 16:28
> > A : FreeTDS Development Group
> > Objet : RE: [freetds] Inserting data into tables[Ce message a ete
> > verifie]
> >
> >
> > > From: Pascal Miquet
> > > Sent: Wednesday, November 24, 2004 2:50 AM
> > >
> > > pid: 1783:tds_get_string: reading 68 from wire to give 34 to
client.
> > > pid: 1783:tds_get_string: reading 20 from wire to give 10 to
client.
> > > pid: 1783:08:48:32.135486 processing result tokens.  marker is
> > fd(DONE)
> > > pid: 1783:08:48:32.135542 tds_process_end: more_results = 0
> > >                 was_cancelled = 0
> > >                 error = 1
> > >                 done_count_valid = 0
> > > pid: 1783:08:48:32.135600 tds_process_end() state set to TDS_IDLE
> > > pid: 1783:SQLFreeHandle(3, 0xa1b39a0)
> > > pid: 1783:SQLFreeHandle(3, 0xa1a3130)
> >
> > Pascal, give us enough to help you!  I asked for the log, not just
10
> > lines of it!
> >
> > If you don't want to post the whole thing, just post the end,
starting
> > with the last line that looks like "13:40:07.147239 Sending packet".
> > I'd like to see the whole packet sent, and the server's complete
> > response.  You don't usually get "error = 1" without something else
> > arriving first.
> >
> > Also, for the record, what version of FreeTDS?
> >
> > Regards,
> >
> > --jkl
> >
> > > -----Message d'origine-----
> > > De : freetds-bounces AT lists.ibiblio.org
> > > [mailto:freetds-bounces AT lists.ibiblio.org]De la part de James K.
> > Lowden
> > > Envoye : mercredi 24 novembre 2004 08:10
> > > A : FreeTDS Development Group
> > > Objet : Re: [freetds] Inserting data into tables[Ce message a ete
> > > verifie]
> > >
> > >
> > > "Pascal Miquet" <p.miquet AT hafiba.fr> wrote:
> > > >
> > > > I was wrong with my affirmation. Using the isql stuff data are
> > correctly
> > > > inserted.
> > >
> > > Well, that's good, actually.  ;-)
> > >
> > > > But using PHP with ODBC connection, the stuff isn't correct and
I've
> > got
> > > > a warning.
> > > > According many reading, I thought that the error reported should
be
> > on a
> > > > 6 digit code, but the PHP error log give me a warning with a
state
> > of
> > > > 00000, and the insert command is not done.
> > > >
> > > > Any Idea to make tests ?
> > >
> > > It's hard to say, without seeing the text of the messages you're
> > getting.
> > >
> > >
> > > Now that we know the server is OK, the answer probably lies in the
> > > application logic.  Perhaps you didn't finish reading your results
> > before
> > > issuing the INSERT statement?  Still, in that case, you should
have
> > seen a
> > > message from the server (or even from FreeTDS itself).
> > >
> > > If you can post a TDSDUMP log of the session, I think that will
make
> > the
> > > situation much clearer.
> > >
> > > --jkl
> > >
> > >
> > > > Regards
> > > >
> > > > -----Message d'origine-----
> > > > De : freetds-bounces AT lists.ibiblio.org
> > > > [mailto:freetds-bounces AT lists.ibiblio.org]De la part de James K.
> > Lowden
> > > > Envoye : mercredi 24 novembre 2004 07:18
> > > > A : FreeTDS Development Group
> > > > Objet : Re: [freetds] Inserting data into tables[Ce message a
ete
> > > > verifie]
> > > >
> > > >
> > > > "Pascal Miquet" <p.miquet AT hafiba.fr> wrote:
> > > > > Thanks for your reply, but the insert command is issued into
the
> > isql
> > > > > interface.
> > > > > The command is something like
> > > > > INSERT LOG(EventId,loginID) VALUES ('1','155')
> > > > >
> > > > > I've also validate the dump of freeTDS into a log file, and
see
> > > > > nothing special.
> > > >
> > > > Please post the TDSDUMP log.  I don't see how it could be
anything
> > > > except server-side, but the log should show evidence of the
> > rejection,
> > > > and why.
> > > >
> > > > I would be good if the SQL were something like:
> > > >
> > > > INSERT LOG(EventId,loginID) VALUES ('1','155')
> > > > SELECT EventId,loginID from LOG where EventID = 1
> > > >
> > > > --jkl
> > > >
> > > >
> > > >
> > > > > -----Message d'origine-----
> > > > > De : freetds-bounces AT lists.ibiblio.org
> > > > > [mailto:freetds-bounces AT lists.ibiblio.org]De la part de
Lowden,
> > James
> > > > > K Envoye : mardi 23 novembre 2004 16:13
> > > > > A : FreeTDS Development Group
> > > > > Objet : RE: [freetds] Inserting data into tables[Ce message a
ete
> > > > > verifie]
> > > > >
> > > > >
> > > > > > From: Pascal Miquet
> > > > > > Sent: Tuesday, November 23, 2004 10:05 AM
> > > > > >
> > > > > > I've configured freeTDS to be used with the unixODBC to
connect
> > to
> > > > > > an
> > > > > MS SQL
> > > > > > server.
> > > > > > If I use the isql interface to issue some SELECT commands,
all
> > > > > > return
> > > > > are
> > > > > > correct.
> > > > > > BUT I can't issue an ISNERT command.
> > > > > > The result is "SQLRowCount returns -1"
> > > > > > Is there some flags to allow freeTDS to issue such INSERT
> > commands ?
> > > > >
> > > > > If you're issuing SQL text like "insert T values ('a', 'b')",
> > FreeTDS
> > > > > is only conveying the SQL to the server (there's nothing
special
> > about
> > > > > INSERT).  If the row isn't inserted, there's a problem with
> > > > > permissions or the data, or you've violated the "process all
> > results"
> > > > > rule in your application.
> > > > >
> > > > > I suggest you try the command with isql or tsql to see if you
get
> > a
> > > > > more useful error message.
> > > > >
> > > > > HTH.
> > > > >
> > > > > --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.
If you, as the intended recipient of this message, the purpose of which is to 
inform and update our clients, prospects and consultants of developments 
relating to our services and products, would not like to receive further 
e-mail correspondence from the sender, please "reply" to the sender 
indicating your wishes.  In the U.S.: 1345 Avenue of the Americas, New York, 
NY 10105.