[freetds] [Fwd: Problems configuring php with freetds]
me at mikesoh.com
me at mikesoh.com
Thu Jun 5 14:01:42 EDT 2008
Nope...no SELinux. I have Ubuntu
I tried doing a fopensock on the server. PHP opens the socket using
fopensock, but cannot use mssql_connect.
> Date: Wed, 4 Jun 2008 22:07:38 +0200
> From: Daniel Fazekas <fdsubs at t-online.hu>
> Subject: Re: [freetds] [Fwd: Problems configuring php with freetds]
> To: FreeTDS Development Group <freetds at lists.ibiblio.org>
> Message-ID: <FAB7FD48-72D5-4D2D-9109-2ACB87FA83CB at t-online.hu>
> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
> On Jun 4, 2008, at 21:58, me at mikesoh.com wrote:
>> Warning: mssql_connect() [function.mssql-connect]: Unable to open
>> socket (severity 9) in /home/sohmc/www/mssql_functions.php on line 4
>> Any thoughts?
> Maybe you got a RHEL, Fedora, CentOS or similar system with SELinux?
> If so, you'll have to allow remote database connections.
> Try first (more restrictive):
> setsebool -P httpd_can_network_connect_db 1
> If that didn't help, do:
> setsebool -P httpd_can_network_connect 1
> Message: 4
> Date: Thu, 5 Jun 2008 07:29:00 -0400
> From: "Federico Alves" <sales at minixel.com>
> Subject: [freetds] TDsPool
> To: <freetds at lists.ibiblio.org>
> Message-ID: <008001c8c6ff$5b3ca3c0$11b5eb40$@com>
> Content-Type: text/plain; charset="us-ascii"
> I have a business problem that could only be solved by using TDSpool, but
> find that it would not work with tds version 8 (SQL Server 2005). Any
> we could update tdspool? The connections should be "poollable", meaning
> even if the client process issues a disconnect, freetds would keep the
> connection open for another 3 mins waiting to see if another process wants
> to open a similar connection. This period should be configurable. This
> change would be revolutionary.
> Message: 5
> Date: Thu, 5 Jun 2008 15:29:05 +0200
> From: "ZIGLIO, Frediano, VF-IT" <Frediano.Ziglio at vodafone.com>
> Subject: Re: [freetds] Problem retrieveing results from a query withan
> IMAGE field
> To: "FreeTDS Development Group" <freetds at lists.ibiblio.org>
> <72EBB5FADDA71343B78E1F09FF471F6E45288E at OBOMEXO02.omnitel.it>
> Content-Type: text/plain; charset=us-ascii
>> Il giorno mer, 04/06/2008 alle 15.05 -0300, Daniel A. Veiga
>> ha scritto:
>> > This is the TDSDUMP log generated for the same program I sent the
>> > unixODBC log file for. I hope it helps ...
>> > Daniel
>> it helps, it helps :)
>> The code which cause the problem is in _SQLFetch
>> /* TODO change when we code cursors support... */
>> /* stop looping, forward cursor support only one row */
>> num_rows = 1;
>> well.. this tell to stop processing rows if an unbinded
>> column is found.
>> This is done to allow getting results using SQLGetData
>> however we send a
>> cursor fetch for 20 rows so in this case we have still to read 19 rows
>> when SQLFetchScroll returns :(
>> Well... for forward only cursors this is correct for perhaps
>> for cursors
>> is not... I think the correct processing should be fetch all
>> 20 rows or
>> request only a row (I think the last is the most probable)...
>> I'll have
>> to test.
> commenting num_rows = 1 line seems to fix the problem. Under ODBC 2
> SQLFetch returns only a row and does not take into account fetched_ptr,
> array_size and status_ptr.
> FreeTDS mailing list
> FreeTDS at lists.ibiblio.org
> End of FreeTDS Digest, Vol 65, Issue 4
More information about the FreeTDS