Re: sometimes sql is returning wrong data to application

Michal Seliga <[email protected]>
Newsgroups gmane.comp.db.tds.freetds
Message-ID <[email protected]>
maybe its data related?
i constantly see this behaviour on one special result, nowhere else. btw its not
true that with debug version of libtdsodbc.so it gives always same string
appended to result, sometimes i get numbers....

i even tried to run appplication with valgrind, i got tons of errors, but
nothing what could be related to this

i will continue to search for its cause (or at least finda way how to reproduce
it properly), i will write when there will be some news

Frediano Ziglio wrote:
> MS renamed protocol so now "old" 8.0 is called 7.1 (continue to use 8.0
> for compatibility, 0.82 does not like 7.1 that much ;) ).
> I'm unable to reproduce your problem :(
> Very strange... 
> 
> freddy77
> 
> Il giorno mar, 08/12/2009 alle 12.25 +0100, Michal Seliga ha scritto:
>> note that i use protocol version 8.0, not 7.x
>> to me it seems like some trailing 0 is missing... but i don't know where, i
>> don't understand code very well yet. i am going to try with cvs head version,
>> just in case that something new already fixed it
>>
>> Frediano Ziglio wrote:
>>> Well... the fact that occurs even in no-optimized code is fine, it means
>>> that is not a compiler or stack overflow problem. dummyTS is used for
>>> TEXT as timestamp... however timestamp is stored in another place... not
>>> into text buffer so how could dummyTS finish in text output buffer?
>>> Probably this is due to a varchar(max) field which is not supported by
>>> TDS protocol 7.1 so is returned like a TEXT field... have you other
>>> varchar/text fields in your result? 
>>>
>>> I'll look deeper...
>>>
>>> freddy77
>>>
>>> Il giorno lun, 07/12/2009 alle 16.24 +0100, Michal Seliga ha scritto:
>>>> update - it happened with not optimized version of odbc library too :( only this
>>>> time garbage is not so random, if there is problem then there is text 'dummyTS'
>>>> appended to the end of result. i don't know where it came from
>>>>
>>>> Michal Seliga wrote:
>>>>> this problem is strange and i am not able to find out what happens
>>>>>
>>>>> i am using freetds + iodbc + qt and i am connection to mssql 2005 database
>>>>>
>>>>> *sometimes* i get wrong result from long varchar field. usually its good when
>>>>> query is launched at the beginning and it suddnly stop working when it happens
>>>>> later, when application is running for several minutes.
>>>>>
>>>>> when i compiled libtdsodbc.c without optimalizations (-O0 instead of -O2 in
>>>>> Makefile in odbc directory) then everything started to behave well and this
>>>>> didn't happened anymore
>>>>>
>>>>> it looks to me that something wasn't initialized properly with optimalizations
>>>>> enabled, but i am not able to find out what exactly it could be. when library
>>>>> was compiled with -O2 there were some warnings, maybe they were related, maybe
>>>>> not, i don't know.
>>>>>
>>>>> i tried to do some tracing, but with -O0 there is no problem and with -O2
>>>>> tracing is not very useful so i learned nothing.... i hope developers will have
>>>>> more luck
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> FreeTDS mailing list
>>>>> [email protected]
>>>>> http://lists.ibiblio.org/mailman/listinfo/freetds
>>>>>
>>>> _______________________________________________
>>>> FreeTDS mailing list
>>>> [email protected]
>>>> http://lists.ibiblio.org/mailman/listinfo/freetds
>>> _______________________________________________
>>> FreeTDS mailing list
>>> [email protected]
>>> http://lists.ibiblio.org/mailman/listinfo/freetds
>>>
>> _______________________________________________
>> FreeTDS mailing list
>> [email protected]
>> http://lists.ibiblio.org/mailman/listinfo/freetds
> 
> _______________________________________________
> FreeTDS mailing list
> [email protected]
> http://lists.ibiblio.org/mailman/listinfo/freetds
>
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.