Re: [Fwd: Problems configuring php with freetds]

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 <[email protected]>
> Subject: Re: [freetds] [Fwd: Problems configuring php with freetds]
> To: FreeTDS Development Group <[email protected]>
> Message-ID: <[email protected]>
> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
>
> On Jun 4, 2008, at 21:58, [email protected] 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" <[email protected]>
> Subject: [freetds] TDsPool
> To: <[email protected]>
> 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
> I
> find that it would not work with tds version 8 (SQL Server 2005). Any
> chance
> we could update tdspool? The connections should be "poollable", meaning
> that
> 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" <[email protected]>
> Subject: Re: [freetds] Problem retrieveing results from a query	withan
> 	IMAGE	 field
> To: "FreeTDS Development Group" <[email protected]>
> Message-ID:
> 	<[email protected]>
> 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.
>
> freddy77
>
>
> ------------------------------
>
> _______________________________________________
> FreeTDS mailing list
> [email protected]
> http://lists.ibiblio.org/mailman/listinfo/freetds
>
>
> End of FreeTDS Digest, Vol 65, Issue 4
> **************************************
>
>