php-windows Digest 6 Apr 2004 19:07:25 -0000 Issue 2197
Topics (messages 23369 through 23386):
Re: Using PHP on Server 2003...
23369 by: David Elliott
23380 by: Jason Boomer
23382 by: Svensson, B.A.T. (HKG)
Re: ODBC or MS SQL DLL? WAS: Using PHP on Server 2003...
23370 by: Svensson, B.A.T. (HKG)
23371 by: David Elliott
23372 by: Svensson, B.A.T. (HKG)
23373 by: Svensson, B.A.T. (HKG)
23374 by: Robert Twitty
23375 by: Svensson, B.A.T. (HKG)
23376 by: David Felton
23377 by: Svensson, B.A.T. (HKG)
23378 by: Robert Twitty
23379 by: Gerardo Rojas
23381 by: Svensson, B.A.T. (HKG)
23384 by: Robert Twitty
23386 by: David Elliott
$_FILES array returns undefined index
23383 by: Ron.Herhuth.tatumpartners.com
23385 by: DvDmanDT
Administrivia:
To subscribe to the digest, e-mail:
[EMAIL PROTECTED]
To unsubscribe from the digest, e-mail:
[EMAIL PROTECTED]
To post to the list, e-mail:
[EMAIL PROTECTED]
----------------------------------------------------------------------
--- Begin Message ---
Hi B.A.T.
On 06 April 2004 at 08:53:07 +0200 (which was 07:53 where I live) Svensson,
B.A.T. (HKG) wrote
> You have made sure that the ms sql extension is available in the php ini
> file, as well made sure that the ms sql dll is in the same directory as
> php.exe?
If possible don't use the mssql extension but use the ODBC one. To my
knowledge it has not changed since MSSQL 6.5 and is unreliable. You can run
into problems if you run a query and then do a header location.
--
Thanks, _______________________________________________
David | David Elliott | Software Engineer |
_________________________| [EMAIL PROTECTED] | PGP Key ID 0x650F4534 |
| "You've got all the emotions of a stone" - Quark |
--- End Message ---
--- Begin Message ---
>Ok, I rebuilt a fresh server with the same config as my original
post. This time I put a copy of the php_mssql.dll in the C:\PHP
directory right along side the php.exe. But when I try to register
the dll I get "DLLRegisterServer entry point not found".
NOTE: The only changes I've made to the C:\Windows\php.ini at this
point is to un-comment out the php_mssql.dll extension, and set the
"extension_dir" to C:\php, if that helps at all...
I know there has to be something really simple that I'm missing but I
cannot figure it out. Thanks again for any help.
>
>
>---- Original Message ----
>From: [EMAIL PROTECTED]
>To: [EMAIL PROTECTED]
>Subject: RE: [PHP-WIN] Using PHP on Server 2003...
>Date: Tue, 6 Apr 2004 08:53:07 +0200
>
>>Just for the protocol:
>>
>>You have made sure that the ms sql extension is available in the
>>php ini file, as well made sure that the ms sql dll is in the same
>directory
>>as php.exe?
>>
>>
>>-----Original Message-----
>>From: Jason Boomer
>>To: [EMAIL PROTECTED]
>>Sent: 2004-04-06 03:36
>>Subject: [PHP-WIN] Using PHP on Server 2003...
>>
>>I'm trying to setup PHP to run on Windows 2003 running IIS 6 and SQL
>>Server 2000 SP2. I'm able to setup PHP itself with no problem; the
>>"phpinfo.php" page opens fine. The problem I have is when I try to
>setup
>>either "phpwebsite" or "phpbb". For some reason I continue to get a
>>"Database not found" error. I've verified everything with the
>database
>>itself and it works fine. I'm able to run a test query against the
>database
>>with the user I setup and I've also had a DB Admin friend of mine
>verify
>>that the database is setup correctly and it is. We even tried
>MySQL, and an
>>Access DB but all 3 always return the same error when trying to
>configure
>>either "phpwebsite", or "phpbb".
>>
>>
>>
>>Has anybody else run into this? Any help would be much appreciated.
>>Thanks
>>a lot!
>>
>>--
>>PHP Windows Mailing List (http://www.php.net/)
>>To unsubscribe, visit: http://www.php.net/unsub.php
>>
>>
--- End Message ---
--- Begin Message ---
I don't think it should be needed (I did it by experimenting and reading
the manuals when I set up PHP and IIS6.0) but if you uses php as a cgi
you might need the DLL as an executable with in IIS as well. But as I
said, I am not to sure about this...
On Tue, 2004-04-06 at 17:09, Jason Boomer wrote:
> >Ok, I rebuilt a fresh server with the same config as my original
> post. This time I put a copy of the php_mssql.dll in the C:\PHP
> directory right along side the php.exe. But when I try to register
> the dll I get "DLLRegisterServer entry point not found".
>
> NOTE: The only changes I've made to the C:\Windows\php.ini at this
> point is to un-comment out the php_mssql.dll extension, and set the
> "extension_dir" to C:\php, if that helps at all...
>
> I know there has to be something really simple that I'm missing but I
> cannot figure it out. Thanks again for any help.
> >
> >
> >---- Original Message ----
> >From: [EMAIL PROTECTED]
> >To: [EMAIL PROTECTED]
> >Subject: RE: [PHP-WIN] Using PHP on Server 2003...
> >Date: Tue, 6 Apr 2004 08:53:07 +0200
> >
> >>Just for the protocol:
> >>
> >>You have made sure that the ms sql extension is available in the
> >>php ini file, as well made sure that the ms sql dll is in the same
> >directory
> >>as php.exe?
> >>
> >>
> >>-----Original Message-----
> >>From: Jason Boomer
> >>To: [EMAIL PROTECTED]
> >>Sent: 2004-04-06 03:36
> >>Subject: [PHP-WIN] Using PHP on Server 2003...
> >>
> >>I'm trying to setup PHP to run on Windows 2003 running IIS 6 and SQL
> >>Server 2000 SP2. I'm able to setup PHP itself with no problem; the
> >>"phpinfo.php" page opens fine. The problem I have is when I try to
> >setup
> >>either "phpwebsite" or "phpbb". For some reason I continue to get a
> >>"Database not found" error. I've verified everything with the
> >database
> >>itself and it works fine. I'm able to run a test query against the
> >database
> >>with the user I setup and I've also had a DB Admin friend of mine
> >verify
> >>that the database is setup correctly and it is. We even tried
> >MySQL, and an
> >>Access DB but all 3 always return the same error when trying to
> >configure
> >>either "phpwebsite", or "phpbb".
> >>
> >>
> >>
> >>Has anybody else run into this? Any help would be much appreciated.
> >>Thanks
> >>a lot!
> >>
> >>--
> >>PHP Windows Mailing List (http://www.php.net/)
> >>To unsubscribe, visit: http://www.php.net/unsub.php
> >>
> >>
>
--- End Message ---
--- Begin Message ---
>>You have made sure that the ms sql extension is available in the
>>php ini file, as well made sure that the ms sql dll is in the
>>same directory as php.exe?
>If possible don't use the mssql extension but use the ODBC one. To my
>knowledge it has not changed since MSSQL 6.5 and is unreliable. You can
>run into problems if you run a query and then do a header location.
I am using php as fast-cgi on the same type of server configuration, i.e.
Win2003, IIS6, MSSQL server 2000, etc, and have exprienced no real problem
yet.
So I am curious about this. Would you like to explain this a little bit more
in details?
--- End Message ---
--- Begin Message ---
Hi B.A.T.
On 06 April 2004 at 09:28:20 +0200 (which was 08:28 where I live) Svensson,
B.A.T. (HKG) emanated these words of wisdom
>>>You have made sure that the ms sql extension is available in the
>>>php ini file, as well made sure that the ms sql dll is in the
>>>same directory as php.exe?
>>If possible don't use the mssql extension but use the ODBC one. To my
>>knowledge it has not changed since MSSQL 6.5 and is unreliable. You can
>>run into problems if you run a query and then do a header location.
> I am using php as fast-cgi on the same type of server configuration, i.e.
> Win2003, IIS6, MSSQL server 2000, etc, and have exprienced no real problem
> yet.
> So I am curious about this. Would you like to explain this a little bit more
> in details?
1) You can not do complex queries. e.g.
=============8<=============================================================
begin transaction
set nocount on
declare
@PerId int
, @ConId int
, @DelID int
, @BilID int
insert into
table1 (id,Name)
Values(42,'A Name')
set @PerId = @@identity
-- other inserts and data manipulation
set nocount off
commit
select
@PerId PersId
,@ConId ContId
,@BilId BillId
,@DelId DeliId
=============8<=============================================================
2) You sometimes (i.e. not always therefore not reproducible) get a CGI error
if you use header("Location:http://xxx.xxx.xxx.xx";) to redirect address
after a database query, you will sometimes get CGI Error message.
Here is the CGI Error message source code:
=============8<=============================================================
<head><title>Error in CGI Application</title></head>
<body><h1>CGI Error</h1>The specified CGI application misbehaved by not
returning a complete set of HTTP headers. The headers it did return
are:<p><p><pre></pre>
=============8<=============================================================
I have set up two servers at the same time on the same hardware one never
showed this the other would sometimes (about 1 in 7 calls). Guess witch one
was used as the test server and which one was the production server?
--
Thank you for your time, _______________________________________________
David | David Elliott | Software Engineer |
_________________________| [EMAIL PROTECTED] | PGP Key ID 0x650F4534 |
| * <- Tribble = <- McTribble Sandwich |
--- End Message ---
--- Begin Message ---
Thanks, I will try this out at work today.
> So I am curious about this. Would you like to explain this a little
> bit more in details?
1) You can not do complex queries. e.g.
=============8<=========================================================
====
--- End Message ---
--- Begin Message ---
Haven't tested your suggestion yet, but just look through it more
carefully now. (Comments follow below).
In general:
The only special thing I can see that you are using in your code,
that I am not using in my stored procedures are transactions - I
think so at least. Except for that I am using all other stuff, and
have no problem with it.
> > So I am curious about this. Would you like to explain this a little bit more
> > in details?
>
> 1) You can not do complex queries. e.g.
> =============8<=============================================================
> begin transaction
>
> set nocount on
>
> declare
> @PerId int
> , @ConId int
> , @DelID int
> , @BilID int
>
> insert into
> table1 (id,Name)
> Values(42,'A Name')
> set @PerId = @@identity
This looks strange, id must be an identity column for this to work,
and since you have not turned on identity insert I assume id is not
an identity column.
> -- other inserts and data manipulation
>
> set nocount off
Why do you turn on row counts just before you return the result?
This might create problems in the receiving end.
> commit
>
> select
> @PerId PersId
> ,@ConId ContId
> ,@BilId BillId
> ,@DelId DeliId
>
> =============8<=============================================================
>
> 2) You sometimes (i.e. not always therefore not reproducible) get a CGI error
>
> if you use header("Location:http://xxx.xxx.xxx.xx";) to redirect address
> after a database query, you will sometimes get CGI Error message.
>
> Here is the CGI Error message source code:
>
> =============8<=============================================================
>
> <head><title>Error in CGI Application</title></head>
> <body><h1>CGI Error</h1>The specified CGI application misbehaved by not
> returning a complete set of HTTP headers. The headers it did return
> are:<p><p><pre></pre>
I recognize this error, but I get it in another context, namely when
stderr is not redirect to stdout when I execute a shell command with
popen(). It might be that the SQL server sends an error message form
time to time(?) (would it help to do a "set ansi_warnings off"?)
The other reason why you might get this error is - but I am not 100%
sure about this, since I got it some times when I worked with db calls,
and just fixed the fault but forgot to document the fault it self -
because some of the return values are nulls. You can fix this by
typically doing like this:
SELECT
isnull(@PerdId, -1) PersId,
isnull(...),
etc, etc..
Might be worth to test?
> =============8<=============================================================
>
> I have set up two servers at the same time on the same hardware one never
> showed this the other would sometimes (about 1 in 7 calls). Guess witch one
> was used as the test server and which one was the production server?
:)
--- End Message ---
--- Begin Message ---
The best extension for accessing MS SQL Server is the odbtp extension at
http://odbtp.sourceforge.net. The odbc and mssql extensions both have
limitations when used with SQL Server 2000.
mssql ext:
- Uses the obsolete, unsupported and non thread safe DB-Library.
- Does not support varchar(>255), nvarchar and ntext fields.
- Cannot use FOR XML clause in SQL.
odbc ext:
- Uses ODBC 2 instead of ODBC 3.
- Does not provide support for stored procedures.
- Does not support nvarchar and ntext fields.
The odbtp extension is considerably faster than the odbc extension, and is
just as fast as the mssql extension. It also provides support for all of
the mssql_* functions, which means it can be used as a "seemless"
replacement for the mssql extension. And, unlike the odbc and mssql
extensions, the behaviour of the odbtp extension is the same on Linux/UNIX
platforms.
-- bob
On Tue, 6 Apr 2004, Svensson, B.A.T. (HKG) wrote:
> >>You have made sure that the ms sql extension is available in the
> >>php ini file, as well made sure that the ms sql dll is in the
> >>same directory as php.exe?
>
> >If possible don't use the mssql extension but use the ODBC one. To my
> >knowledge it has not changed since MSSQL 6.5 and is unreliable. You can
> >run into problems if you run a query and then do a header location.
>
> I am using php as fast-cgi on the same type of server configuration, i.e.
> Win2003, IIS6, MSSQL server 2000, etc, and have exprienced no real problem
> yet.
>
> So I am curious about this. Would you like to explain this a little bit more
> in details?
--- End Message ---
--- Begin Message ---
On Tue, 2004-04-06 at 14:52, Robert Twitty wrote:
> The best extension for accessing MS SQL Server is the odbtp extension at
> http://odbtp.sourceforge.net. The odbc and mssql extensions both have
> limitations when used with SQL Server 2000.
>
> mssql ext:
> - Uses the obsolete, unsupported and non thread safe DB-Library.
> - Does not support varchar(>255), nvarchar and ntext fields.
Just tried this out, and indeed the driver just returned a string
with lenght 255 when I in fact returned a string of 1000 chars.
That is a sever problem for me, since I frequently needs to
return strings much longer than 255 characters. Bad, bad, bad...
Is there absolutely now way to change this?
> - Cannot use FOR XML clause in SQL.
>
> odbc ext:
> - Uses ODBC 2 instead of ODBC 3.
> - Does not provide support for stored procedures.
> - Does not support nvarchar and ntext fields.
I don't uses ODBC for other reasons: Is imply does not trust
it reliability to transport large data sets - sometimes ODBC
drops rows without any particular reason and without raising
an error - and as such fault can't naturally not be encountered.
> The odbtp extension is considerably faster than the odbc extension, and is
> just as fast as the mssql extension. It also provides support for all of
> the mssql_* functions, which means it can be used as a "seemless"
> replacement for the mssql extension. And, unlike the odbc and mssql
> extensions, the behaviour of the odbtp extension is the same on Linux/UNIX
> platforms.
I'll have a look at this.
Anyhow, thanks for your feedback, it was very helpfully.
--- End Message ---
--- Begin Message ---
Yes there is this workaround:
if you run this query first
@mssql_query( "SET TEXTSIZE 1024000", $db);
then when you want to retrieve a field of type ntext or whatever use the
following syntax in your sql:
SELECT CAST(fieldname AS TEXT) ...
-----Original Message-----
From: Svensson, B.A.T. (HKG) [mailto:[EMAIL PROTECTED]
Sent: 06 April 2004 2:23
To: [EMAIL PROTECTED]
Subject: Re: [PHP-WIN] Re: ODBC or MS SQL DLL? WAS: Using PHP on Server
2003...
On Tue, 2004-04-06 at 14:52, Robert Twitty wrote:
> The best extension for accessing MS SQL Server is the odbtp extension at
> http://odbtp.sourceforge.net. The odbc and mssql extensions both have
> limitations when used with SQL Server 2000.
>
> mssql ext:
> - Uses the obsolete, unsupported and non thread safe DB-Library.
> - Does not support varchar(>255), nvarchar and ntext fields.
Just tried this out, and indeed the driver just returned a string
with lenght 255 when I in fact returned a string of 1000 chars.
That is a sever problem for me, since I frequently needs to
return strings much longer than 255 characters. Bad, bad, bad...
Is there absolutely now way to change this?
> - Cannot use FOR XML clause in SQL.
>
> odbc ext:
> - Uses ODBC 2 instead of ODBC 3.
> - Does not provide support for stored procedures.
> - Does not support nvarchar and ntext fields.
I don't uses ODBC for other reasons: Is imply does not trust
it reliability to transport large data sets - sometimes ODBC
drops rows without any particular reason and without raising
an error - and as such fault can't naturally not be encountered.
> The odbtp extension is considerably faster than the odbc extension, and is
> just as fast as the mssql extension. It also provides support for all of
> the mssql_* functions, which means it can be used as a "seemless"
> replacement for the mssql extension. And, unlike the odbc and mssql
> extensions, the behaviour of the odbtp extension is the same on Linux/UNIX
> platforms.
I'll have a look at this.
Anyhow, thanks for your feedback, it was very helpfully.
--
PHP Windows Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.
This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.
**********************************************************************
--- End Message ---
--- Begin Message ---
Thanx a million times David!
I just tested your suggestion and it works just fine!
(But I put all the code in the sp's instead)
I had a look at the odbtp.sourceforge.net site, and I
realized that this would take a time to transfer the
current code I built based on the mssql ext.
With your suggestion, I can easy alter a couple of
stored procedures and it will the work out just
fine with.
Thanks again for saving me much time here!
On Tue, 2004-04-06 at 15:28, David Felton wrote:
> Yes there is this workaround:
> if you run this query first
> @mssql_query( "SET TEXTSIZE 1024000", $db);
>
> then when you want to retrieve a field of type ntext or whatever use the
> following syntax in your sql:
> SELECT CAST(fieldname AS TEXT) ...
>
> -----Original Message-----
> From: Svensson, B.A.T. (HKG) [mailto:[EMAIL PROTECTED]
> Sent: 06 April 2004 2:23
> To: [EMAIL PROTECTED]
> Subject: Re: [PHP-WIN] Re: ODBC or MS SQL DLL? WAS: Using PHP on Server
> 2003...
>
>
> On Tue, 2004-04-06 at 14:52, Robert Twitty wrote:
> > The best extension for accessing MS SQL Server is the odbtp extension at
> > http://odbtp.sourceforge.net. The odbc and mssql extensions both have
> > limitations when used with SQL Server 2000.
> >
> > mssql ext:
> > - Uses the obsolete, unsupported and non thread safe DB-Library.
> > - Does not support varchar(>255), nvarchar and ntext fields.
>
> Just tried this out, and indeed the driver just returned a string
> with lenght 255 when I in fact returned a string of 1000 chars.
>
> That is a sever problem for me, since I frequently needs to
> return strings much longer than 255 characters. Bad, bad, bad...
>
> Is there absolutely now way to change this?
>
> > - Cannot use FOR XML clause in SQL.
> >
> > odbc ext:
> > - Uses ODBC 2 instead of ODBC 3.
> > - Does not provide support for stored procedures.
> > - Does not support nvarchar and ntext fields.
>
> I don't uses ODBC for other reasons: Is imply does not trust
> it reliability to transport large data sets - sometimes ODBC
> drops rows without any particular reason and without raising
> an error - and as such fault can't naturally not be encountered.
>
>
> > The odbtp extension is considerably faster than the odbc extension, and is
> > just as fast as the mssql extension. It also provides support for all of
> > the mssql_* functions, which means it can be used as a "seemless"
> > replacement for the mssql extension. And, unlike the odbc and mssql
> > extensions, the behaviour of the odbtp extension is the same on Linux/UNIX
> > platforms.
>
> I'll have a look at this.
>
> Anyhow, thanks for your feedback, it was very helpfully.
>
> --
> PHP Windows Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
> **********************************************************************
> This email and any files transmitted with it are confidential and
> intended solely for the use of the individual or entity to whom they
> are addressed. If you have received this email in error please notify
> the system manager.
>
> This footnote also confirms that this email message has been swept by
> MIMEsweeper for the presence of computer viruses.
> **********************************************************************
--- End Message ---
--- Begin Message ---
If you use the php_odbtp_mssql.dll extension, and follow the instructions
at http://odbtp.sourceforge.net/phpext.html#mssql, then you don't have to
change your code or your stored procedures.
-- bob
On 6 Apr 2004, Svensson, B.A.T. (HKG) wrote:
> Thanx a million times David!
>
> I just tested your suggestion and it works just fine!
> (But I put all the code in the sp's instead)
>
> I had a look at the odbtp.sourceforge.net site, and I
> realized that this would take a time to transfer the
> current code I built based on the mssql ext.
>
> With your suggestion, I can easy alter a couple of
> stored procedures and it will the work out just
> fine with.
>
> Thanks again for saving me much time here!
>
>
> On Tue, 2004-04-06 at 15:28, David Felton wrote:
> > Yes there is this workaround:
> > if you run this query first
> > @mssql_query( "SET TEXTSIZE 1024000", $db);
> >
> > then when you want to retrieve a field of type ntext or whatever use the
> > following syntax in your sql:
> > SELECT CAST(fieldname AS TEXT) ...
> >
> > -----Original Message-----
> > From: Svensson, B.A.T. (HKG) [mailto:[EMAIL PROTECTED]
> > Sent: 06 April 2004 2:23
> > To: [EMAIL PROTECTED]
> > Subject: Re: [PHP-WIN] Re: ODBC or MS SQL DLL? WAS: Using PHP on Server
> > 2003...
> >
> >
> > On Tue, 2004-04-06 at 14:52, Robert Twitty wrote:
> > > The best extension for accessing MS SQL Server is the odbtp extension at
> > > http://odbtp.sourceforge.net. The odbc and mssql extensions both have
> > > limitations when used with SQL Server 2000.
> > >
> > > mssql ext:
> > > - Uses the obsolete, unsupported and non thread safe DB-Library.
> > > - Does not support varchar(>255), nvarchar and ntext fields.
> >
> > Just tried this out, and indeed the driver just returned a string
> > with lenght 255 when I in fact returned a string of 1000 chars.
> >
> > That is a sever problem for me, since I frequently needs to
> > return strings much longer than 255 characters. Bad, bad, bad...
> >
> > Is there absolutely now way to change this?
> >
> > > - Cannot use FOR XML clause in SQL.
> > >
> > > odbc ext:
> > > - Uses ODBC 2 instead of ODBC 3.
> > > - Does not provide support for stored procedures.
> > > - Does not support nvarchar and ntext fields.
> >
> > I don't uses ODBC for other reasons: Is imply does not trust
> > it reliability to transport large data sets - sometimes ODBC
> > drops rows without any particular reason and without raising
> > an error - and as such fault can't naturally not be encountered.
> >
> >
> > > The odbtp extension is considerably faster than the odbc extension, and is
> > > just as fast as the mssql extension. It also provides support for all of
> > > the mssql_* functions, which means it can be used as a "seemless"
> > > replacement for the mssql extension. And, unlike the odbc and mssql
> > > extensions, the behaviour of the odbtp extension is the same on Linux/UNIX
> > > platforms.
> >
> > I'll have a look at this.
> >
> > Anyhow, thanks for your feedback, it was very helpfully.
> >
> > --
> > PHP Windows Mailing List (http://www.php.net/)
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
> >
> > **********************************************************************
> > This email and any files transmitted with it are confidential and
> > intended solely for the use of the individual or entity to whom they
> > are addressed. If you have received this email in error please notify
> > the system manager.
> >
> > This footnote also confirms that this email message has been swept by
> > MIMEsweeper for the presence of computer viruses.
> > **********************************************************************
>
> --
> PHP Windows Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
--- End Message ---
--- Begin Message ---
Does this extension allow us to generate SQL scripts? Such as to create a table?
Similar to SQLDMO?
--
Gerardo S. Rojas
mailto: [EMAIL PROTECTED]
-----Original Message-----
From: Robert Twitty [mailto:[EMAIL PROTECTED]
Sent: Tuesday, April 06, 2004 9:51 AM
To: Svensson, B.A.T. (HKG)
Cc: [EMAIL PROTECTED]
Subject: RE: [PHP-WIN] Re: ODBC or MS SQL DLL? WAS: Using PHP on Server
2003...
If you use the php_odbtp_mssql.dll extension, and follow the instructions
at http://odbtp.sourceforge.net/phpext.html#mssql, then you don't have to
change your code or your stored procedures.
-- bob
On 6 Apr 2004, Svensson, B.A.T. (HKG) wrote:
> Thanx a million times David!
>
> I just tested your suggestion and it works just fine!
> (But I put all the code in the sp's instead)
>
> I had a look at the odbtp.sourceforge.net site, and I
> realized that this would take a time to transfer the
> current code I built based on the mssql ext.
>
> With your suggestion, I can easy alter a couple of
> stored procedures and it will the work out just
> fine with.
>
> Thanks again for saving me much time here!
>
>
> On Tue, 2004-04-06 at 15:28, David Felton wrote:
> > Yes there is this workaround:
> > if you run this query first
> > @mssql_query( "SET TEXTSIZE 1024000", $db);
> >
> > then when you want to retrieve a field of type ntext or whatever use the
> > following syntax in your sql:
> > SELECT CAST(fieldname AS TEXT) ...
> >
> > -----Original Message-----
> > From: Svensson, B.A.T. (HKG) [mailto:[EMAIL PROTECTED]
> > Sent: 06 April 2004 2:23
> > To: [EMAIL PROTECTED]
> > Subject: Re: [PHP-WIN] Re: ODBC or MS SQL DLL? WAS: Using PHP on Server
> > 2003...
> >
> >
> > On Tue, 2004-04-06 at 14:52, Robert Twitty wrote:
> > > The best extension for accessing MS SQL Server is the odbtp extension at
> > > http://odbtp.sourceforge.net. The odbc and mssql extensions both have
> > > limitations when used with SQL Server 2000.
> > >
> > > mssql ext:
> > > - Uses the obsolete, unsupported and non thread safe DB-Library.
> > > - Does not support varchar(>255), nvarchar and ntext fields.
> >
> > Just tried this out, and indeed the driver just returned a string
> > with lenght 255 when I in fact returned a string of 1000 chars.
> >
> > That is a sever problem for me, since I frequently needs to
> > return strings much longer than 255 characters. Bad, bad, bad...
> >
> > Is there absolutely now way to change this?
> >
> > > - Cannot use FOR XML clause in SQL.
> > >
> > > odbc ext:
> > > - Uses ODBC 2 instead of ODBC 3.
> > > - Does not provide support for stored procedures.
> > > - Does not support nvarchar and ntext fields.
> >
> > I don't uses ODBC for other reasons: Is imply does not trust
> > it reliability to transport large data sets - sometimes ODBC
> > drops rows without any particular reason and without raising
> > an error - and as such fault can't naturally not be encountered.
> >
> >
> > > The odbtp extension is considerably faster than the odbc extension, and is
> > > just as fast as the mssql extension. It also provides support for all of
> > > the mssql_* functions, which means it can be used as a "seemless"
> > > replacement for the mssql extension. And, unlike the odbc and mssql
> > > extensions, the behaviour of the odbtp extension is the same on Linux/UNIX
> > > platforms.
> >
> > I'll have a look at this.
> >
> > Anyhow, thanks for your feedback, it was very helpfully.
> >
> > --
> > PHP Windows Mailing List (http://www.php.net/)
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
> >
> > **********************************************************************
> > This email and any files transmitted with it are confidential and
> > intended solely for the use of the individual or entity to whom they
> > are addressed. If you have received this email in error please notify
> > the system manager.
> >
> > This footnote also confirms that this email message has been swept by
> > MIMEsweeper for the presence of computer viruses.
> > **********************************************************************
>
> --
> PHP Windows Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
--
PHP Windows Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
--- End Message ---
--- Begin Message ---
Maybe, but I still need to add code, and that means more code to
maintain, more code to execute, more loopholes for bug, etc.
In any case, the problem was easy solved by the suggestion David gave.
On Tue, 2004-04-06 at 16:50, Robert Twitty wrote:
> If you use the php_odbtp_mssql.dll extension, and follow the instructions
> at http://odbtp.sourceforge.net/phpext.html#mssql, then you don't have to
> change your code or your stored procedures.
>
> -- bob
>
> On 6 Apr 2004, Svensson, B.A.T. (HKG) wrote:
>
> > Thanx a million times David!
> >
> > I just tested your suggestion and it works just fine!
> > (But I put all the code in the sp's instead)
> >
> > I had a look at the odbtp.sourceforge.net site, and I
> > realized that this would take a time to transfer the
> > current code I built based on the mssql ext.
> >
--- End Message ---
--- Begin Message ---
On 6 Apr 2004, Svensson, B.A.T. (HKG) wrote:
> Maybe, but I still need to add code, and that means more code to
> maintain, more code to execute, more loopholes for bug, etc.
>
That's precisely why odbtp is better. You don't have to perform loopholes
like those suggested by David to accomodate for bugs that will never be
fixed. The bugs in the php_mssql.dll are not the fault of it's creator,
but rather DB-Library. Microsoft stop supporting it after SQL Server 6.5,
and will never fix its bugs. The problem I had was that there were
no loopholes for the bugs I encountered. For example, there is no
loophole for not being able to execute
SELECT * FROM SomeTable FOR XML AUTO
Personally, I don't like the idea of having to change perfectly good SQL
in order to work around driver imperfections. Anyway, good luck, and stay
away from real, nvarchar and ntext fields, I wasn't as lucky. :-)
-- bob
> In any case, the problem was easy solved by the suggestion David gave.
>
--- End Message ---
--- Begin Message ---
Dear B.A.T.
On 06 April 2004 at 14:40:29 +0200 (which was 13:40 where I live) Svensson,
B.A.T. (HKG) might have written
> Haven't tested your suggestion yet, but just look through it more
> carefully now. (Comments follow below).
> In general:
> The only special thing I can see that you are using in your code,
> that I am not using in my stored procedures are transactions
I always use transactions because I don't want information in the tables with
out the correct links in it.
> I think so at least. Except for that I am using all other stuff, and have
> no problem with it.
>>> So I am curious about this. Would you like to explain this a little bit more
>>> in details?
< ... >
>> set @PerId = @@identity
> This looks strange, id must be an identity column for this to work,
The SQL was slight incorrect sorry about that. Below is the full SQL I need
to insert.
=============8<=============================================================
begin transaction
set nocount on
declare
@PerId int
, @ConId int
, @DelID int
, @BilID int
insert into
WebItem (ItemTypeid,Name,LastUpdated,LegacyId)
Values(42,'',Current_timestamp,'090974248')
set @PerId = @@identity
insert into
WebItem (ItemTypeid,Name,LastUpdated,LegacyId)
Values(48,'xxxxx',Current_timestamp,'090974248')
set @ConId = @@identity
insert into
WebAddress
(ItemId,CompanyName,Bldg,Street,Area,District,Town,County,PCode,CountryId,Phone,AttLine)
Values
(@ConId,'xxxxx','xxxxx','xxxxx',''
,'','','','xxxxx','258'
,'','')
insert into
WebItem (ItemTypeid,Name,LastUpdated,LegacyId)
Values(50,'xxxxx',Current_timestamp,'090974248')
set @DelID = @@identity
insert into
WebAddress
(ItemId,CompanyName,Bldg,Street,Area,District,Town,County,PCode,CountryId,Phone,AttLine)
Values
(@DelId,'xxxxx','xxxxx','xxxxx',''
,'','','','xxxxx','258'
,'','')
insert into
WebItem (ItemTypeid,Name,LastUpdated,LegacyId)
Values(49,'xxxxx',Current_timestamp,'090974248')
set @BilID = @@identity
insert into
WebAddress
(ItemId,CompanyName,Bldg,Street,Area,District,Town,County,PCode,CountryId,Phone,AttLine)
Values
(@BilId,'xxxxx','xxxxx','xxxxx',''
,'','','','xxxxx','258'
,'xxxxxx','')
insert into
WebPerson
(ItemId,CompanyName,FirstName,LastName,Dear,TitleID,EmailAddress,Phone1,Phone2,Fax,PWord
,PwordPhrase,VatNO,ContID,BillID,DeliID,DistId,ContTyp,CustTyp,MailList,UpdateMe)
Values
(@PerId,'xxxxx','David','Elliott'
,'','141','[EMAIL PROTECTED]','xxxxxx',''
,'','password','','drff'
,@ConId,@BilId,@DelId,'50482','email','Other','','')
insert into WebItemlink
(itemlinktypeid,itemid,ite_itemid,lastupdated)
values
(52,50385,@PerId,current_timestamp)
insert into WebItemlink
(itemlinktypeid,itemid,ite_itemid,lastupdated)
values
(52,50386,@PerId,current_timestamp)
insert into WebItemlink
(itemlinktypeid,itemid,ite_itemid,lastupdated)
values
(52,50393,@PerId,current_timestamp)
insert into WebItemlink
(itemlinktypeid,itemid,ite_itemid,lastupdated)
values
(52,50395,@PerId,current_timestamp)
insert into WebItemlink
(itemlinktypeid,itemid,ite_itemid,lastupdated)
values
(52,50399,@PerId,current_timestamp)
insert into WebItemlink
(itemlinktypeid,itemid,ite_itemid,lastupdated)
values
(52,50403,@PerId,current_timestamp)
insert into WebItemlink
(itemlinktypeid,itemid,ite_itemid,lastupdated)
values
(52,50406,@PerId,current_timestamp)
insert into WebItemlink
(itemlinktypeid,itemid,ite_itemid,lastupdated)
values
(52,50409,@PerId,current_timestamp)
insert into WebItemlink
(itemlinktypeid,itemid,ite_itemid,lastupdated)
values
(52,50410,@PerId,current_timestamp)
set nocount off
commit
select
@PerId PersId
,@ConId ContId
,@BilId BillId
,@DelId DeliId
=============8<=============================================================
> and since you have not turned on identity insert I assume id is not an
> identity column.
< ... >
>> set nocount off
> Why do you turn on row counts just before you return the result?
> This might create problems in the receiving end.
This way you get a record count of 1 for that select statement you are just
about to execute.
>> commit
>>
>> select
>> @PerId PersId
>> ,@ConId ContId
>> ,@BilId BillId
>> ,@DelId DeliId
>>
>> =============8<=============================================================
>>
>> 2) You sometimes (i.e. not always therefore not reproducible) get a CGI error
>>
>> if you use header("Location:http://xxx.xxx.xxx.xx";) to redirect address
>> after a database query, you will sometimes get CGI Error message.
>>
>> Here is the CGI Error message source code:
>>
>> =============8<=============================================================
>>
>> <head><title>Error in CGI Application</title></head>
>> <body><h1>CGI Error</h1>The specified CGI application misbehaved by not
>> returning a complete set of HTTP headers. The headers it did return
>> are:<p><p><pre></pre>
> I recognize this error, but I get it in another context, namely when
> stderr is not redirect to stdout when I execute a shell command with
> popen(). It might be that the SQL server sends an error message form time
> to time(?) (would it help to do a "set ansi_warnings off"?)
Good pointer. I will try that.
> The other reason why you might get this error is - but I am not 100%
> sure about this, since I got it some times when I worked with db calls,
> and just fixed the fault but forgot to document the fault it self -
> because some of the return values are nulls. You can fix this by
> typically doing like this:
> SELECT
> isnull(@PerdId, -1) PersId,
> isnull(...),
> etc, etc..
> Might be worth to test?
I might have a go at that as well
--
Bye, _______________________________________________
David | David Elliott | Software Engineer |
_________________________| [EMAIL PROTECTED] | PGP Key ID 0x650F4534 |
| Demon Spawn Graphix (C) 1995 by McFly |
--- End Message ---
--- Begin Message ---
I'm trying to do a file upload using PHP. I am using this form element on
th first page:
<input type="FILE" name="userfile" size="36">
On the second page I'm attempting to access the file name to figure out
how to access it using this code:
echo $_FILES['userfile']['name'];
I get an undefined index userfile...error
What am I doing/not doing right here?
Thanks,
ROn
--- End Message ---
--- Begin Message ---
Maybe you forgot the enctype="multipart/form-data" in the <form> tag?
--
// DvDmanDT
MSN: dvdmandt€hotmail.com
Mail: dvdmandt€telia.com
"Ron Herhuth" <[EMAIL PROTECTED]> skrev i meddelandet
news:[EMAIL PROTECTED]
I'm trying to do a file upload using PHP. I am using this form element on
th first page:
<input type="FILE" name="userfile" size="36">
On the second page I'm attempting to access the file name to figure out
how to access it using this code:
echo $_FILES['userfile']['name'];
I get an undefined index userfile...error
What am I doing/not doing right here?
Thanks,
ROn
--- End Message ---
