[PHP-DEV] ibase_fetch_object and ibase_fetch_row patch (bug #15602)
Hi, I have read Daniela Mariaschi solution to return NULL and empty fields from ibase_fetch_row() and ibase_fetch_object(), but don't have experiencie for apply the patch. Any help in this way? Sorry for my pour english... eXParTaKus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] this is the Daniela Mariachi message
this is the Daniela Mariachi...
Following up from bug #15602, I have written a patch to return NULL and
empty fields from ibase_fetch_row() and ibase_fetch_object().
The current implementation of those two functions skips (ignores) empty or
NULL fields, returning rows of different lenghts in a result set, depending
of the number of NULL fields in each row.
Daniela Mariaschi
Index: interbase.c
===
RCS file: /repository/php4/ext/interbase/interbase.c,v
retrieving revision 1.75
diff -r1.75 interbase.c
2109c2109
break;
---
break;
2119c2119,2125
} /* if not null */
---
} else {
if (fetch_type FETCH_ARRAY) {
add_index_null(return_value, i);
} else {
add_property_null(return_value,
var-aliasname);
}
}
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] run-test output
I would prefer using ob_end_clean() instead of ob_implicit_flush().
This way what ever settings one uses you can see the progress
of the tests.
marcus
cvs -z3 -q diff run-tests.php (in directory S:\php4-HEAD\)
Index: run-tests.php
===
RCS file: /repository/php4/run-tests.php,v
retrieving revision 1.106
diff -u -r1.106 run-tests.php
--- run-tests.php 2 Nov 2002 12:33:24 - 1.106
+++ run-tests.php 2 Nov 2002 12:39:05 -
-44,7 +44,7
$cwd = getcwd();
set_time_limit(0);
-ob_implicit_flush();
+ob_end_clean();
error_reporting(E_ALL);
ini_set('magic_quotes_runtime',0); // this would break tests by modifying
EXPECT sections
Re: [PHP-DEV] Re: cvs: php4 /ext/iconv config.m4
Feel free :-) - Stig Thanks, Stig! Then I'm adding to EXTENSIONS a entry for iconv module. Any objections...? Moriyoshi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Missing info about configure
Perhaps someone should add the missing info for configure here. marcus cvs -z3 -q diff tsrm.m4 (in directory S:\php4-ZE1\TSRM\) Index: tsrm.m4 === RCS file: /repository/TSRM/tsrm.m4,v retrieving revision 1.14 diff -u -r1.14 tsrm.m4 --- tsrm.m4 5 Oct 2002 11:26:17 - 1.14 +++ tsrm.m4 2 Nov 2002 13:12:51 - -102,7 +102,7 ]) AC_ARG_WITH(tsrm-st, -[ --with-tsrm-st],[ +[ --with-tsrm-st Use SGI's State Threads],[ TSRM_ST=$withval ],[ TSRM_ST=no
[PHP-DEV] Rsync and Snaps
Hey all, Rsync and snaps are going to be inactive for much of this week. We are moving boxes, and this will mean we are going to take down the service at the beginning of the week, and it may not return until late in the week. If you have any cron jobs that rely on these services (particularly rsync) you may wish to comment them out to reduce server noise. Thanks, James -- James Cox :: [EMAIL PROTECTED] :: http://james.blogs.at/ Was I helpful? http://www.amazon.co.uk/exec/obidos/wishlist/23IVGHQ61RJGO/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] OCISaveLob, OCILoadLob, OCISaveFile?
On Thu, Oct 31, 2002 at 08:18:12PM +0100, Jean Tardy wrote: Hello, Who know haw to use those functions:OCISaveLob, OCILoadLob, OCISaveFile? Where can I find documentation and sample about this general purpose: 'lob object manipulation with oracle Thanks. http://conf.php.net/slides/oci/paper.txt -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- Thies C. Arntzen - Looking for all sorts of freelance work - just ask.. http://www.amazon.de/exec/obidos/wishlist/AB9DY62QWDSZ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] ltconfig - No such file or directory
Configuring Zend
checking build system type... i386-unknown-freebsd4.7
checking for ld used by GCC... /usr/libexec/elf/ld
checking if the linker (/usr/libexec/elf/ld) is GNU ld... yes
checking for BSD-compatible nm... /usr/bin/nm -B
updating cache ./config.cache
./ltconfig: Can't open ./ltconfig: No such file or directory
configure: error: libtool configure failed
What's going wrong?
$ automake --version
automake (GNU automake) 1.5
$ autoconf --version
Autoconf version 2.13
$ bison --version
bison (GNU Bison) 1.75
$ libtool --version
ltmain.sh (GNU libtool) 1.4.3 (1.922.2.110 2002/10/23 01:39:54)
I've also tried autoconf-2.53, which then does not produce the errors
that can be seen in buildconf.out, but still no difference: ltconfig is
not found.
What fails is:
/usr/local/bin/bash ./ltconfig --no-reexec --cache-file=/dev/null
--disable-shared --with-gcc --with-gnu-ld --no-verify ./ltmain.sh
executed from configure as of line 90'738:
# Actually configure libtool. ac_aux_dir is where install-sh is found.
CC=$CC CFLAGS=$CFLAGS CPPFLAGS=$CPPFLAGS \
LD=$LD LDFLAGS=$LDFLAGS LIBS=$LIBS \
LN_S=$LN_S NM=$NM RANLIB=$RANLIB \
DLLTOOL=$DLLTOOL AS=$AS OBJDUMP=$OBJDUMP \
${CONFIG_SHELL-/bin/sh} $ac_aux_dir/ltconfig --no-reexec \
$libtool_flags --no-verify $ac_aux_dir/ltmain.sh $lt_target \
|| { { echo $as_me:$LINENO: error: libtool configure failed 5
echo $as_me: error: libtool configure failed 2;}
{ (exit 1); exit 1; }; }
Where (or when) is ltconfig created? Or why is it used? CVS log of
ltconfig (1.22) says: Remove ltconfig which is not used anymore by
libtool 1.4 - so why *is* it being used?
Maybe config.log helps, you can find it at
http://sitten-polizei.de/php/config.log (174 KB)
If I do a cvs update -r1.21 ltconfig, this error does not occur, but
then, later on:
checking whether dlsym() requires a leading underscore in symbol
names... ./configure: line 92000: syntax error near unexpected token
`_LT_AC_TRY_DLOPEN_SELF('
./configure: line 92000: `_LT_AC_TRY_DLOPEN_SELF('
which, as I guess, has something to do with the error mentioned in
buildconf-2.53.out. Where does this come from?
So, what I did to get all this running:
1) get ltconfig from CVS, r1.21
2) specify 'i386-portbld-freebsd4.7' at end of ./configure-line
to get rid of warning you must specify host if --no-verify is set
3) comment out lines in configure that could'nt be expanded my m4
(starting with _LT_AC_TRY_DLOPEN_SELF()
4) put SED='sed' into libtool (in php directory) since it was empty
This is some ugly hack, working for me, but this cannot be intended, can
it?
Sorry for being such a lamer: Timm
using default Zend directory
buildconf: checking installation...
buildconf: autoconf version 2.13 (ok)
buildconf: automake version 1.5 (ok)
buildconf: libtool version 1.4.3 (ok)
WARNING: automake and libtool are installed in different
directories. This may cause aclocal to fail.
continuing anyway
rebuilding configure
autoconf: Undefined macros:
***BUG in Autoconf--please report*** AC_TRY_DLOPEN_SELF
configure.in:1124:AC_DEFINE([HAVE_BUILD_DEFS_H], 1, [ ])
configure.in:146:AC_MSG_RESULT(${1}.${2} (ok))
configure.in:232:AC_MSG_RESULT([$PHP_SAPI])
configure.in:284: AC_DEFINE(HAVE_LIBDL, 1, [ ])
configure.in:409: AC_DEFINE(HAVE_SOCKADDR_STORAGE,1,[Whether you have struct
sockaddr_storage])
configure.in:418:[AC_DEFINE(HAVE_SOCKADDR_LEN,1,[Whether sockaddr struct has sa_len])],
configure.in:504: AC_DEFINE(HAVE_GETADDRINFO,1,[Define if you have the getaddrinfo
function])
configure.in:531:dnl AC_MSG_RESULT([$ac_cv_type_in_addr_t])
configure.in:533: AC_DEFINE(in_addr_t, u_int, [ ])
configure.in:621: AC_DEFINE(PHP_SAFE_MODE,1,[ ])
configure.in:623: AC_DEFINE(PHP_SAFE_MODE,0,[ ])
configure.in:633: AC_DEFINE(PHP_SAFE_MODE_EXEC_DIR,/usr/local/php/bin, [ ])
configure.in:634: AC_MSG_RESULT([/usr/local/php/bin])
configure.in:636: AC_DEFINE_UNQUOTED(PHP_SAFE_MODE_EXEC_DIR,$withval, [ ])
configure.in:637: AC_MSG_RESULT([$withval])
configure.in:640:AC_DEFINE(PHP_SAFE_MODE_EXEC_DIR,/usr/local/php/bin, [ ])
configure.in:641:AC_MSG_RESULT([/usr/local/php/bin])
configure.in:644: AC_DEFINE(PHP_SAFE_MODE_EXEC_DIR,/usr/local/php/bin, [ ])
configure.in:645: AC_MSG_RESULT([/usr/local/php/bin])
configure.in:652: AC_DEFINE(PHP_SIGCHILD, 1, [ ])
configure.in:654: AC_DEFINE(PHP_SIGCHILD, 0, [ ])
configure.in:661: AC_DEFINE(MAGIC_QUOTES, 1, [ ])
configure.in:663: AC_DEFINE(MAGIC_QUOTES, 0, [ ])
configure.in:686: AC_DEFINE(DEFAULT_SHORT_OPEN_TAG,1,[ ])
configure.in:688: AC_DEFINE(DEFAULT_SHORT_OPEN_TAG,0,[ ])
configure.in:698:AC_DEFINE(HAVE_DMALLOC,1,[Whether you have dmalloc])
configure.in:709: AC_DEFINE(HAVE_IPV6,1,[Whether to enable IPv6 support])
configure.in:728: AC_DEFINE(HAVE_CRYPT,1,[ ])
configure.in:781:AC_MSG_RESULT([$PHP_VERSIONING])
configure.in:826: AC_DEFINE(ZTS,1,[ ])
configure.in:947:AC_DEFINE_UNQUOTED(PHP_BUILD_DATE,$PHP_BUILD_DATE,[PHP build date])
Re: [PHP-DEV] run-test output
On Sat, Nov 02, 2002 at 01:42:32PM +0100, Marcus Boerger wrote:
I would prefer using ob_end_clean() instead of ob_implicit_flush().
This way what ever settings one uses you can see the progress
of the tests.
Ok, but wouldn't it be even better to do:
while(ob_get_level()) {
ob_end_clean();
}
This way we are sure that _all_ output buffers are closed (maybe someone
has zlib.output_compression on, or an auto_prepend file that starts a
couple of buffers...)
Sander
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [PATCH] ereg to pcre conversion
Unfortunately I have to agree with Markus on this.
If we don't care very much about the risk of breaking backwards
compatibility then altering calls to the ereg functions is a perfectly fine
idea.
If we *do* care about backwards compatibility then *before* committing the
changes in any permanent fashion we need to be pretty near certain there
aren't any surprises. With the ereg functions any change could easily
impact thousands of sites.
We all miss things from time to time, so to be reasonably confident about
the changes you will need some peer review. This could be a lot of work.
Lacking time from a couple regex-gurus, you will want to make clear the
semantic equivalence of your changes. This means compiling a list of the
differences between ereg and pcre, and the corresponding changes in the
code.
With lots of eyeballs we *should* be able to spot any differences not
properly identified. Once clearly explained and understood the risk is much
less.
This can be a lot of work :).
The flip side is once done you could have code useful to far more than just
PHP. An adaptor to allow the pcre code to be used whereever the old regex
code was used might be useful to others.
-Original Message-
From: Markus Fischer [mailto:mfischer;guru.josefine.at]
Sent: Friday, November 01, 2002 11:12 PM
To: Ilia A.
Cc: [EMAIL PROTECTED]
Subject: Re: [PHP-DEV] [PATCH] ereg to pcre conversion
I somehow don't like the idea. Mostly because I fear we
introduce some BC change regarding to the ereg*
functionality we yet do not forsee which brings us in the end
more trouble (i.e. use complaining) then it's really worth.
Just let ereg* functions stay where they are, if people
complain because something doesn't work, rather tell them to
use the pcre* family.
After your patch, how sure can you be that all ereg* pattern
will work without any trouble? This would mean testing many
use apps out there ... is it worth the work?
Also, I haven't seen much maintainance needed in the both the
existing regular expression code.
I simply don't see a reason to change the inner functionality
and risk to introduce BC problems.
Also I don't see a reason to drop the ereg* function in some
future point (I see the point with emulating them, but see
above).
-1
On Thu, Oct 31, 2002 at 02:47:27PM -0500, Ilia A. wrote :
Currently PHP ships with two regular expression libraries that are both
installed by default, PCRE regex. The regex library that is responsible
for
ereg_* functions is fairly old and offers a very limited functionality
compared to the PCRE library. In most cases the PCRE functions are also
much
faster then the old ereg functions.
I would like to propose that we drop the old ereg library and use only
a single regular expression library, PCRE. For BC purposes I've written a
patch (see attached file), which emulates the old ereg_* functions for
people
who still rely on those, using PCRE.
This cleanup would mean we'd only need to maintain one set of regular
expression code, which as far as code goes is pretty complex as well as
give
speed-up for people still using ereg.
Perhaps, at some future point this would allow us to drop the ereg_*
functions
all together.
Ilia
Index: pcre/php_pcre.c
===
RCS file: /repository/php4/ext/pcre/php_pcre.c,v
retrieving revision 1.130
diff -u -3 -p -r1.130 php_pcre.c
--- pcre/php_pcre.c 24 Oct 2002 19:06:19 - 1.130
+++ pcre/php_pcre.c 31 Oct 2002 13:57:58 -
@@ -553,6 +553,110 @@ static void php_pcre_match(INTERNAL_FUNC
}
/* }}} */
+/* {{{ ereg_to_pcre_convert
+*/
+static inline zval *ereg_to_pcre_convert(zval **reg_expr, int case_sens)
+{
+ char *p, *pp;
+ int extra_len = 3;
+ zval *new_reg;
+
+ if (case_sens) {
+ extra_len++;
+ }
+
+ MAKE_STD_ZVAL(new_reg);
+
+ Z_STRVAL_P(new_reg) = emalloc(Z_STRLEN_PP(reg_expr) * 2 + extra_len +
1);
+ Z_TYPE_P(new_reg) = IS_STRING;
+
+ pp = Z_STRVAL_PP(reg_expr);
+ p = Z_STRVAL_P(new_reg);
+
+ *p++ = '/';
+ while (*pp) {
+ if (*pp != '/') {
+ *p++ = *pp;
+ } else {
+ *p++ = '\\';
+ *p++ = '/';
+ extra_len++;
+ }
+ pp++;
+ }
+
+ *p++ = '/';
+ if (case_sens) {
+ *p++ = 'i';
+ }
+ *p++ = 's';
+ *p = '\0';
+
+ Z_STRLEN_P(new_reg) = Z_STRLEN_PP(reg_expr) + extra_len;
+
+ return new_reg;
+}
+/* }}} */
+
+/* {{{ php_pcre_ereg_match
+*/
+static void php_pcre_ereg_match(INTERNAL_FUNCTION_PARAMETERS, int
case_sens)
+{
+ zval **old_regex, **m_string, **subpats = NULL;
+ zval **args[3];
+ zval *retval, *pcre_func, *new_regx;
+
+ int argc = ZEND_NUM_ARGS();
+
+ if ((argc != 2 argc !=
[PHP-DEV] ext/sybase_ct commit?
Round 2 - fight:-) OK, I guess now I'm ready for committing my changes. I got PHP compiled and tested out the new functionality of my ext/sybase_ct changes against CVS from today. Just to make sure I'm getting it all right: This is what I'd put in the commit message - Implemented features/changes requested in Bug #16960 (Timm): . Added a new function sybase_unbuffered_query() . Added a new function sybase_fetch_assoc() . Added sybase_set_message_handler() which enables users to handle server messages in a callback function . Added an ini entry for deadlock retries - retrying deadlocks can cause transaction state to break (sybct.deadlock_retry_count, defaults to -1 forever). . Fixed sybase_fetch_object() not to return object with numeric members . Fixed issues with identical fieldnames . Made sybase_fetch_*() functions return correct datatypes . Made phpinfo() section more verbose . Made sybase_query() error messages more verbose I also wrote some documentation, the diffs against the current one are available at: http://sitten-polizei.de/php/documentation.diff The added files are: http://sitten-polizei.de/php/sybase-fetch-assoc.xml http://sitten-polizei.de/php/sybase-set-message-handler.xml http://sitten-polizei.de/php/sybase-unbuffered-query.xml If needed, I could also provide documentation in German. -- Timm Any sufficiently advanced bug is indistinguishable from a feature -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] ODBTP, a possible solution for MS-SQL and other databases
Hello
(NOTE: This message was originally posted to PHP-DB, but I was told that
PHP-DEV was a more appropriate place)
I have been using PHP for about 9 months, and have chosen it as my primary
scripting language for web applications. I have and still use ASP and JSP.
IMHO, PHP is superior and easier to use than those languages except in one
area that is important to me, which is the ability to access MS SQL Server
7.0 / 2000 databases from a UNIX box. Out of the box PHP provides great
support for MySQL and PostgreSQL, and at this time I have no desire to use
them because I do not believe that they are ready for prime time. The
open source solution that is always recommended for UNIX-based PHP / MS-SQL
connectivity is freeTDS, and unfortunately I found it to be quite lacking in
its capabilities and useless in certain situations. Another alternative
was to use a commercial ODBC driver management system on UNIX. Sadly, it
was not in the budget for this endeavor, and the PHP odbc extensions could
use some work in terms of ease of use.
Because I was determined to use PHP (I really dislike using JSP / JDBC on
UNIX, and IIS / ASP is out of the question), I decided to create my own
solution. Since I have a substantial amount of experience in programming
directly with the Win32 ODBC API and TCP/IP, I decided to create a service
that runs on a Win32 platform that can communicate with any platform via
TCP/IP. The service uses a home grown protocol that allows a client to
access any database that the service can see via the ODBC drivers that are
installed on the computer which it resides. In other words, it allows a PHP
client on UNIX to access a database using the ODBC drivers installed on a
Windows NT / 2000 server. It is nothing more than a middle man service for
Win32 ODBC. The name of the service is called ODBTP (Open Database
Transport Protocol), and no there is not a RFC for this protocol. Thus
far, I have successfully accessed MS-SQL, Oracle and Sybase databases via
ODBTP.
ODBTP consists of a Windows NT / 2000 service application, an ODBTP client
library that can be used to create Win32 or UNIX clients, and a PHP
extension module that was created with the library. ODBTP has the
following features:
* Multi-client servicing
* True connection pooling (not persistent connections)
* Client reserved connections (virtual connections for stateless web
clients)
* Supports all data types, including nvarchar, ntext, varchar(255),
char(255), datetime, and bigint.
* No big-endian / little-endian problems.
* Server-side data binding.
* Stored procedure execution, parameter passing (including NULL's) and
output retrieval.
* Transactions, i.e., supports commits and rollbacks under any transaction
isolation level.
* UNICODE data is processed using UTF-8 encoding (important since PHP
strings are not UNICODE)
* Can retrieve query results sent in XML format.
* Verbose error reporting, all ODBC error messages are sent to client.
* No discovered memory leaks or buffer overflow possibilities.
* Designed to be as easy as possible to use with PHP
I am new to this mailing list, and it appears that PHP is predominantly used
for MySQL and PostgreSQL, and thus I am not sure if ODBTP is of any interest
to most people on this list. My original intent was not to release ODBTP to
the public (I really don't have the time to maintain freeware), but if
there is a substantial interest I will release it to the public. I am
curious to see how well it performs in other environments.
-- bob
The following is a table, stored procedures and a php script that uses ODBTP
to initialize the table with data.
CREATE TABLE dbo.Employees (
Id int IDENTITY (1, 1) NOT NULL ,
ExtId numeric (15,0) NOT NULL ,
LastName varchar (50) NOT NULL ,
FirstName varchar (50) NOT NULL ,
Title varchar (256) NOT NULL ,
Salary money NOT NULL ,
JobDesc varchar (3000) NULL ,
Notes ntext NULL ,
Active bit NOT NULL ,
DateEntered datetime NOT NULL ,
DateModified datetime NOT NULL ,
CONSTRAINT PKCL_Employees_Id PRIMARY KEY CLUSTERED (
Id
)
)
CREATE PROCEDURE AddEmployee
ExtId numeric(15,0),
LastName varchar(50),
FirstName varchar(50),
Title varchar(256),
Salary money,
JobDesc varchar(3000) = 'Job not defined'
AS
SET NOCOUNT ON
INSERT INTO Employees( ExtId, LastName, FirstName,
Title, Salary, JobDesc )
VALUES( ExtId, LastName, FirstName,
Title, Salary, JobDesc )
IF ERROR 0 RETURN 0
RETURN IDENTITY
GO
CREATE PROCEDURE SetEmployeeNotes
Id int,
Notes ntext
AS
SET NOCOUNT ON
UPDATE Employees SET
Notes = Notes,
DateModified = getdate()
WHERE Id = Id
GO
?php
if( !extension_loaded('odbtp') ) dl('odbtp.so');
$con = odbtp_connect( 'odbtpsvr.somewhere.com',
'DRIVER={SQL
Server};SERVER=sqlsvr.somewhere.com;UID=myuid;PWD=mypwd;DATABASE=OdbtpTest;'
) or die;
Re: [PHP-DEV] ODBTP, a possible solution for MS-SQL and other databases
On Saturday, November 2, 2002, at 12:38 PM, Robert Twitty wrote: its capabilities and useless in certain situations. Another alternative was to use a commercial ODBC driver management system on UNIX. Sadly, it was not in the budget for this endeavor, and the PHP odbc extensions could use some work in terms of ease of use. I tend to disagree with this bit. The ODBC system is no more complicated than any of the other database interfaces you find on PHP. There is the needed introduction of a odbc.ini file, but thats no more confusing than the need for a TNS Names with Oracle. If you have a problem with the way ODBC is implemented, please feel free to request new features via the bug system, submit patches, or emailing me directly. I have in the past asked numerous times for input on the extension only to receive silence. More importantly, what commercial ODBC system are you looking at? unixODBC, and iODBC work wonderfully for UNIX, and both are free and integrated completely with PHP. Because I was determined to use PHP (I really dislike using JSP / JDBC on UNIX, and IIS / ASP is out of the question), I decided to create my own solution. Since I have a substantial amount of experience in programming directly with the Win32 ODBC API and TCP/IP, I decided to create a service that runs on a Win32 platform that can communicate with any platform via TCP/IP. The service uses a home grown protocol that allows a client to access any database that the service can see via the ODBC drivers that are installed on the computer which it resides. In other words, it allows a PHP client on UNIX to access a database using the ODBC drivers installed on a Windows NT / 2000 server. It is nothing more than a middle man service for Win32 ODBC. The name of the service is called ODBTP (Open Database Transport Protocol), and no there is not a RFC for this protocol. Thus far, I have successfully accessed MS-SQL, Oracle and Sybase databases via ODBTP. This sounds like a lot of work to re-implement the ODBC system. * Supports all data types, including nvarchar, ntext, varchar(255), char(255), datetime, and bigint. I'd like to know how you got around this. It's proven to be a bigger headache in supporting for ODBC than I would have imagined. * Stored procedure execution, parameter passing (including NULL's) and output retrieval. Nice.I haven't worked on this yet at all for PHP ODBC. * UNICODE data is processed using UTF-8 encoding (important since PHP strings are not UNICODE) This is being worked upon. Hopefully I'll have free time again soon. * No discovered memory leaks or buffer overflow possibilities. If you know of any in the current PHP ODBC, let us know. --- Dan KalowskyI'll walk a thousand miles just http://www.deadmime.org/~dankto slip this skin. [EMAIL PROTECTED]- Streets of Philadelphia, [EMAIL PROTECTED]Bruce Springsteen -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] ODBTP, a possible solution for MS-SQL and other databases
At 18:38 02.11.2002, Robert Twitty wrote: Hello (NOTE: This message was originally posted to PHP-DB, but I was told that PHP-DEV was a more appropriate place) I have been using PHP for about 9 months, and have chosen it as my primary scripting language for web applications. I have and still use ASP and JSP. IMHO, PHP is superior and easier to use than those languages except in one area that is important to me, which is the ability to access MS SQL Server 7.0 / 2000 databases from a UNIX box. Out of the box PHP provides great support for MySQL and PostgreSQL, and at this time I have no desire to use them because I do not believe that they are ready for prime time. I do not like MySQL due to its simplicity and lack of relations. But i must disagree to PHP/Postgres. Postgres IS very stable and fast. Another very important thing is that any security problem found in postgres is fixed very soon. On the otherhand there is Microsoft and we have seen in the past that there are a lot of problems and that it takes some time to get them fixed by MS. Last but not least i d not like MS products for large server applications for several reasons. The open source solution that is always recommended for UNIX-based PHP / MS-SQL connectivity is freeTDS, and unfortunately I found it to be quite lacking in its capabilities and useless in certain situations. Another alternative was to use a commercial ODBC driver management system on UNIX. Sadly, it was not in the budget for this endeavor, and the PHP odbc extensions could use some work in terms of ease of use. Because I was determined to use PHP (I really dislike using JSP / JDBC on UNIX, and IIS / ASP is out of the question), I decided to create my own solution. Since I have a substantial amount of experience in programming directly with the Win32 ODBC API and TCP/IP, I decided to create a service that runs on a Win32 platform that can communicate with any platform via TCP/IP. The service uses a home grown protocol that allows a client to access any database that the service can see via the ODBC drivers that are installed on the computer which it resides. In other words, it allows a PHP client on UNIX to access a database using the ODBC drivers installed on a Windows NT / 2000 server. It is nothing more than a middle man service for Win32 ODBC. The name of the service is called ODBTP (Open Database Transport Protocol), and no there is not a RFC for this protocol. Thus far, I have successfully accessed MS-SQL, Oracle and Sybase databases via ODBTP. ODBTP consists of a Windows NT / 2000 service application, an ODBTP client library that can be used to create Win32 or UNIX clients, and a PHP extension module that was created with the library. ODBTP has the following features: * Multi-client servicing * True connection pooling (not persistent connections) * Client reserved connections (virtual connections for stateless web clients) * Supports all data types, including nvarchar, ntext, varchar(255), char(255), datetime, and bigint. * No big-endian / little-endian problems. * Server-side data binding. * Stored procedure execution, parameter passing (including NULL's) and output retrieval. * Transactions, i.e., supports commits and rollbacks under any transaction isolation level. * UNICODE data is processed using UTF-8 encoding (important since PHP strings are not UNICODE) did you use mbstring and internal encoding set to utf-8 or ucs-whatever? * Can retrieve query results sent in XML format. * Verbose error reporting, all ODBC error messages are sent to client. * No discovered memory leaks or buffer overflow possibilities. * Designed to be as easy as possible to use with PHP I am new to this mailing list, and it appears that PHP is predominantly used for MySQL and PostgreSQL, and thus I am not sure if ODBTP is of any interest to most people on this list. My original intent was not to release ODBTP to the public (I really don't have the time to maintain freeware), but if there is a substantial interest I will release it to the public. I am curious to see how well it performs in other environments. -- bob Sounds interesting to me :-) There is no problem with adding this as a new extension in pecl since all new extensions should be created there. Maybe it is even worth to discuss this belonging to /ext but i doubt. Just ask for approriate CVS account. However, where can one download ODBTP or will be part of the extension build? regards marcus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Documentation for Zend API for PHP Extensions
I've been looking through the ./ext dir for php-4.2.3 and trying to figure out how to revive the Birdstep (Velocis) database extension. Where I'm running into problems is with the Zend API fnctions. Is there any reference material that describes the functionality and API of the TSRM module? Also, if anyone knows anything about the maintenance status of this module, could you please let me know. TIA -- William D. 'Diggy' Bell Principal DB Software Development http://www.dbsoftdev.com -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] ODBTP, a possible solution for MS-SQL and other databases
Hi Dan Below, I have addressed each of your comments. Keep in mind that ODBTP is not a replacement for ODBC. The motivation for ODBTP was to devise a scheme that would make it easy to keep up with Microsoft's perpetual changes in the TDS protocol. Which from my research appears to be the biggest headache for FreeTDS and ODBC driver developers. ODBTP is less susceptible to this because it is an interface to ODBC drivers installed on a Windows NT / 2000 server. And, so far, Microsoft is still providing full support for its ODBC drivers on Windows Platforms. Also, if they stop supporting ODBC in the future, the ODBTP service can be changed to interface with the new methodology without changing the ODBTP protocol. On Saturday, November 2, 2002, at 12:38 PM, Robert Twitty wrote: its capabilities and useless in certain situations. Another alternative was to use a commercial ODBC driver management system on UNIX. Sadly, it was not in the budget for this endeavor, and the PHP odbc extensions could use some work in terms of ease of use. I tend to disagree with this bit. The ODBC system is no more complicated than any of the other database interfaces you find on PHP. There is the needed introduction of a odbc.ini file, but thats no more confusing than the need for a TNS Names with Oracle. If you have a problem with the way ODBC is implemented, please feel free to request new features via the bug system, submit patches, or emailing me directly. I have in the past asked numerous times for input on the extension only to receive silence. Upon further review, you are probably correct. However, working directly with ODBC can be a daunting task for some people. More importantly, what commercial ODBC system are you looking at? unixODBC, and iODBC work wonderfully for UNIX, and both are free and integrated completely with PHP. The problem with the free versions was that they did not appear to provide support SQL Server 7.0 / 2000 new features. In fact, Microsoft's DB-Library and early ODBC driver versions do not support all of them either. Because I was determined to use PHP (I really dislike using JSP / JDBC on UNIX, and IIS / ASP is out of the question), I decided to create my own solution. Since I have a substantial amount of experience in programming directly with the Win32 ODBC API and TCP/IP, I decided to create a service that runs on a Win32 platform that can communicate with any platform via TCP/IP. The service uses a home grown protocol that allows a client to access any database that the service can see via the ODBC drivers that are installed on the computer which it resides. In other words, it allows a PHP client on UNIX to access a database using the ODBC drivers installed on a Windows NT / 2000 server. It is nothing more than a middle man service for Win32 ODBC. The name of the service is called ODBTP (Open Database Transport Protocol), and no there is not a RFC for this protocol. Thus far, I have successfully accessed MS-SQL, Oracle and Sybase databases via ODBTP. This sounds like a lot of work to re-implement the ODBC system. On the contrary, ODBC was not re-implemented. ODBTP requires it, but on a Windows NT / 2000 Server platform. ODBTP is a client / server wrapper around the Win32 ODBC API. * Supports all data types, including nvarchar, ntext, varchar(255), char(255), datetime, and bigint. I'd like to know how you got around this. It's proven to be a bigger headache in supporting for ODBC than I would have imagined. The ODBTP protocol was designed to handle these new data types. It retrieves data from Microsoft ODBC drivers that fully support these data types, and then sends it to the client via the ODBTP protocol which was designed to accomadate them. The problem you are probably faced with is that the UNIX ODBC drivers do not use or have not fully implemented the new (and supposedly not publically documented) TDS protocol used by SQL Server 7.0 / 2000. * Stored procedure execution, parameter passing (including NULL's) and output retrieval. Nice.I haven't worked on this yet at all for PHP ODBC. Again, the ODBTP protocol has facilities that make this possible. * UNICODE data is processed using UTF-8 encoding (important since PHP strings are not UNICODE) This is being worked upon. Hopefully I'll have free time again soon. No problem, UTF-8 works quite well in PHP. * No discovered memory leaks or buffer overflow possibilities. If you know of any in the current PHP ODBC, let us know. This was not meant to be a point of contention with PHP, but rather with Win32 based services that tend to suffer more from these problems. -- bob --- Dan KalowskyI'll walk a thousand miles just http://www.deadmime.org/~dankto slip this skin. [EMAIL PROTECTED]- Streets of
[PHP-DEV] Re: [PHP-CVS] cvs: php4 / run-tests.php
You can now use php run-test.php ext/whatever
At 22:48 02.11.2002, you wrote:
helly Sat Nov 2 16:48:06 2002 EDT
Modified files:
/php4 run-tests.php
Log:
-allow parameters to be directories
-${dir} - $dir
Index: php4/run-tests.php
diff -u php4/run-tests.php:1.108 php4/run-tests.php:1.109
(bla)
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [PATCH] SNMPv3 support
HI, I have updated the patch send earlier to this list that adds authentication and privacy (SNMPv3) functionality to the SNMP module. The patch is at URL: http://www.lisanza.net/php-snmp/php-netsnmp.patch.txt I would appreciate if the patch will be applied. Harrie Internet Management Consulting mailto: [EMAIL PROTECTED] http://www.lisanza.net/ Author of MOD-SNMP, enabling SNMP management the Apache HTTP server -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] apache_hooks
What do you think would be the best way to make the apache_hooks code more accessible to people? A tarball with the relevant files that overwrites the standard files, or perhaps it is time to #ifdef it into the main branch? -Rasmus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Builing PHP under Windows - need SNMP support
Any guidance on setting up to compile PHP with GNU C-compiler. I want to enable SNMP functionality. Thanks! Walt -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Build PHP under windows - SNMP the objective
What is the best route to building PHP under windows? I've downloaded minGW with a C compiler for windows. My objective is to enable SNMP functionality under Windows. Any guidance greatly appreciated! Thanks! -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] apache_hooks
I think we could produce a snap of this by checking out normally, and then checking out apache_hooks into it, so the files it affects would go to the right tag... (etc etc). I'd be happy to do this when i set up snaps again. -- james What do you think would be the best way to make the apache_hooks code more accessible to people? A tarball with the relevant files that overwrites the standard files, or perhaps it is time to #ifdef it into the main branch? -Rasmus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] ODBTP, a possible solution for MS-SQL and other databases
I do not like MySQL due to its simplicity and lack of relations. But i must disagree to PHP/Postgres. Postgres IS very stable and fast. Another very important thing is that any security problem found in postgres is fixed very soon. On the otherhand there is Microsoft and we have seen in the past that there are a lot of problems and that it takes some time to get them fixed by MS. Last but not least i d not like MS products for large server applications for several reasons. Unfortunately, the place where I work is not comfortable with using open source databases, and SQL Server as been in place for many years and the GUI makes it easier for many people to administer. While it may be unfounded, the majority of the commercial and government world do not appear to be receptive to the use of MySQL and PostgreSQL for serious applications. And M$ is applying enough political pressure to keep it that way. Microsoft is a very big gorilla, and has a reputation for beating superior products with it's sometimes inferior equivalents. * UNICODE data is processed using UTF-8 encoding (important since PHP strings are not UNICODE) did you use mbstring and internal encoding set to utf-8 or ucs-whatever? No, unicode data is coverted to and from UTF-8 on the server-side. The ODBTP protocol sends and receives all unicode data in the UTF-8 format. Sounds interesting to me :-) There is no problem with adding this as a new extension in pecl since all new extensions should be created there. Maybe it is even worth to discuss this belonging to /ext but i doubt. Just ask for approriate CVS account. However, where can one download ODBTP or will be part of the extension build? I have to generate some documentation on how to install and use it. I was only willing to take the time to do this if there was a need for something like ODBTP by other people. -- bob regards marcus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
