headers
ZIGLIO, Frediano, VF-IT | 1 Jun 2007 03:04

Re: Crash selecting a blank TEXT field

> 
> Luke Benstead wrote:
> > 
> > I'm using 0.64. The bug doesn't occur with 0.63 but I get a 
> different
> > bug (duplicate rows returned when there is a warning) with 
> 0.63 that is
> > fixed in 0.64 :)
> 
> 	:-)  And this will be fixed, too, soon.  
> 
> > Setting a text-size does get rid of the crazy numbers, 
> setting a text
> > size of 4000 in freetds.conf, sets the Server column size 
> to 4000 and
> > the client one to 8000. Either way the bug still occurs.
> 
> I.e., it still crashes?  
> 
> > The field is an ntext field that is empty (i.e a blank 
> string, not NULL)
> 
> Thanks.  I think we should add this to our unit tests.  From your
> description it sounds like a server bug.  Where I come from 
> zero-length
> strings have a length of zero, not infinite.  But mine is basically a
> Newtonian existence....
> 

Try using
(Continue reading)

Permalink | Reply | 6 comments |
headers
ZIGLIO, Frediano, VF-IT | 1 Jun 2007 11:05

Re: Crash selecting a blank TEXT field

> > 
> > Luke Benstead wrote:
> > > 
> > > I'm using 0.64. The bug doesn't occur with 0.63 but I get a 
> > different
> > > bug (duplicate rows returned when there is a warning) with 
> > 0.63 that is
> > > fixed in 0.64 :)
> > 
> > 	:-)  And this will be fixed, too, soon.  
> > 
> > > Setting a text-size does get rid of the crazy numbers, 
> > setting a text
> > > size of 4000 in freetds.conf, sets the Server column size 
> > to 4000 and
> > > the client one to 8000. Either way the bug still occurs.
> > 
> > I.e., it still crashes?  
> > 
> > > The field is an ntext field that is empty (i.e a blank 
> > string, not NULL)
> > 
> > Thanks.  I think we should add this to our unit tests.  From your
> > description it sounds like a server bug.  Where I come from 
> > zero-length
> > strings have a length of zero, not infinite.  But mine is 
> basically a
> > Newtonian existence....
> > 
>
(Continue reading)

Permalink | Reply | 5 comments |
headers
Ben Brick | 1 Jun 2007 11:31
Picon

SELECT <at> <at> client_csname - fails with freetds

Hello!

I have a problem running
 SELECT  <at>  <at> client_csname
using FreeTDS.

The variable is empty when I run the SELECT under php4 (Ubuntu
Dapper), but works as normal under php5 (same).

Strangely, other variables (I tested  <at>  <at> connections and  <at>  <at> spid) work fine.

Both interfaces files are the same, the only difference is the version of php.

Why is this?

Many thanks.
Permalink | Reply | 0 comments |
headers
SourceForge.net | 1 Jun 2007 12:11
Picon
Favicon

[ freetds-Patches-1729392 ] locale enhacements for ct-lib

Patches item #1729392, was opened at 2007-06-01 12:11
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=407808&aid=1729392&group_id=33106

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: ct-lib
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: David Nichols (david_nichols)
Assigned to: Nobody/Anonymous (nobody)
Summary: locale enhacements for ct-lib

Initial Comment:
This patch contains support for:
cs_loc_alloc()
cs_loc_drop()

also cs_locale():
CS_SET and CS_GET for:
CS_LC_ALL (only when buffer = 0, CS_SET only)
CS_SYB_CHARSET, CS_SYB_LANG, CS_SYB_LANG_CHARSET

for CS_SYB_SORTORDER I do not know how to set this in the relevant tds structure, so it's commented out for now.
(Continue reading)

Permalink | Reply | 0 comments |
headers
SourceForge.net | 1 Jun 2007 12:29
Picon
Favicon

[ freetds-Patches-1729397 ] locale enhacements for ct-lib

Patches item #1729397, was opened at 2007-06-01 12:29
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=407808&aid=1729397&group_id=33106

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: ct-lib
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: David Nichols (david_nichols)
Assigned to: Nobody/Anonymous (nobody)
Summary: locale enhacements for ct-lib

Initial Comment:
This patch contains support for:
cs_loc_alloc()
cs_loc_drop()

also cs_locale():
CS_SET and CS_GET for:
CS_LC_ALL (only when buffer = 0, CS_SET only)
CS_SYB_CHARSET, CS_SYB_LANG, CS_SYB_LANG_CHARSET

for CS_SYB_SORTORDER I do not know how to set this in the relevant tds structure, so it's commented out for now.
(Continue reading)

Permalink | Reply | 0 comments |
headers
SourceForge.net | 1 Jun 2007 12:30
Picon
Favicon

[ freetds-Patches-1729397 ] locale enhacements for ct-lib

Patches item #1729397, was opened at 2007-06-01 12:29
Message generated for change (Settings changed) made by david_nichols
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=407808&aid=1729397&group_id=33106

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: ct-lib
Group: None
Status: Open
>Resolution: Duplicate
Priority: 5
Private: No
Submitted By: David Nichols (david_nichols)
Assigned to: Nobody/Anonymous (nobody)
Summary: locale enhacements for ct-lib

Initial Comment:
This patch contains support for:
cs_loc_alloc()
cs_loc_drop()

also cs_locale():
CS_SET and CS_GET for:
CS_LC_ALL (only when buffer = 0, CS_SET only)
CS_SYB_CHARSET, CS_SYB_LANG, CS_SYB_LANG_CHARSET

for CS_SYB_SORTORDER I do not know how to set this in the relevant tds structure, so it's commented out for now.
(Continue reading)

Permalink | Reply | 0 comments |
headers
SourceForge.net | 1 Jun 2007 12:31
Picon
Favicon

[ freetds-Patches-1729397 ] duplicate - please ignore

Patches item #1729397, was opened at 2007-06-01 12:29
Message generated for change (Settings changed) made by david_nichols
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=407808&aid=1729397&group_id=33106

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: ct-lib
Group: None
>Status: Deleted
Resolution: Duplicate
>Priority: 1
Private: No
Submitted By: David Nichols (david_nichols)
Assigned to: Nobody/Anonymous (nobody)
>Summary: duplicate - please ignore

Initial Comment:
This patch contains support for:
cs_loc_alloc()
cs_loc_drop()

also cs_locale():
CS_SET and CS_GET for:
CS_LC_ALL (only when buffer = 0, CS_SET only)
CS_SYB_CHARSET, CS_SYB_LANG, CS_SYB_LANG_CHARSET

for CS_SYB_SORTORDER I do not know how to set this in the relevant tds structure, so it's commented out for now.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Brian Paquin | 1 Jun 2007 17:06
Picon
Favicon

Re: Using PHP with FreeTDS

Daniel,

TDSDUMP generates a LOT of output!!
( I redirected the output to a file. When the file reached 2GB,
I killed the job and reviewed file.)
Basically, from what I can tell, it starts fine...
Connects to the database and receives the first packet
of database results. After those lines, it seems like a lot of
repetition (see attached file "log.txt"). Is this output normal?


As for the other suggestions and questions:

I used "php -i" to retrieve the config used by Apple, downloaded PHP  
4.4.4
from php.net, and then rebuilt it (adding in the sybase directive).

Changing the memory limit to 32M did not change the behavior.
(changed php.ini and restarted apache)

otool confirms that FreeTDS is present...
intranet:/Library/WebServer/Documents administrator$ otool -L $ 
(command -v php)
/usr/bin/php:
         /usr/local/lib/libsybdb.5.dylib (compatibility version  
6.0.0, current version 6.0.0)
         /usr/lib/libiodbc.2.dylib (compatibility version 4.0.0,  
current version 4.10.0)
         /System/Library/Frameworks/LDAP.framework/Versions/A/LDAP  
(compatibility version 1.0.0, current version 2.2.0)
(Continue reading)

Permalink | Reply | 5 comments |
headers
Daniel Fazekas | 1 Jun 2007 21:25
Picon
Favicon

Re: Using PHP with FreeTDS

On Jun 1, 2007, at 17:06, Brian Paquin wrote:

> TDSDUMP generates a LOT of output!!
> ( I redirected the output to a file. When the file reached 2GB, I  
> killed the job and reviewed file.)

Definitely shouldn't be getting that big, sounds like it's stuck in  
some infinite loop.

> Connects to the database and receives the first packet of database  
> results. After those lines, it seems like a lot of repetition (see  
> attached file "log.txt"). Is this output normal?

Clearly not normal, but you forgot to attach it, or it was lost  
somewhere along the way, perhaps due to the size of it.
Try sending it up to the first 2-3 repetitions max. Also note that  
sensitive login information may be in the log, you might want to edit  
that out first.

> I used "php -i" to retrieve the config used by Apple, downloaded  
> PHP  4.4.4 from php.net, and then rebuilt it (adding in the sybase  
> directive).

So you didn't apply Apple's custom patches to it, whatever those may  
do -- unlikely to make a difference with the sybase part.
Still, I just don't see the logic of reinstalling PHP this way.
If you're overwriting Apple's version with your own custom-built  
copy, you might as well have went with the current versions of PHP,  
4.4.7 or even 5.2.3. And because you installed it into the same place  
Apple's version used to be, Apple's system updates will likely just
(Continue reading)

Permalink | Reply | 4 comments |
headers
Brian Paquin | 1 Jun 2007 23:25
Picon
Favicon

Re: Using PHP with FreeTDS


I attached the file again (this time compressed into a zip).

I was trying to "modify" php in a upgrade-friendly way, but
you are probably right... I should compile PHP 5.x and then
deal with issues related to OS updates as needed.

I will look into TDSDUMP on the old server this weekend!

Again, thank you!!!

Brian  :)

On Jun 1, 2007, at 3:25 PM, Daniel Fazekas wrote:

> On Jun 1, 2007, at 17:06, Brian Paquin wrote:
>
>> TDSDUMP generates a LOT of output!!
>> ( I redirected the output to a file. When the file reached 2GB, I
>> killed the job and reviewed file.)
>
> Definitely shouldn't be getting that big, sounds like it's stuck in
> some infinite loop.
>
>> Connects to the database and receives the first packet of database
>> results. After those lines, it seems like a lot of repetition (see
>> attached file "log.txt"). Is this output normal?
>
> Clearly not normal, but you forgot to attach it, or it was lost
> somewhere along the way, perhaps due to the size of it.
(Continue reading)

Permalink | Reply | 3 comments |

Gmane