Re: [PHP-DB] Database help needed

[Jason Wong]

> This may sound like an odd question and something that I should know,
> but ...
>
> I need to display results by amount - for example, for all properties
> which are either or between 450,000 and 500,000 (For example) - how
> using PHP and MySQL do I get it to display 450,000, 50,000 and all
> inbetween ???  I can easily get it to display one or the other, but
> it is a search which is based on cost of property.  How will I format
> the MySQL query to get it to do this?

You can do something like:

  SELECT * FROM property WHERE price BETWEEN 45 AND 50;

hth
-- 
Jason Wong -> Gremlins Associates -> www.gremlins.com.hk

/*
Skill without imagination is craftsmanship and gives us many useful 
objects such as wickerwork picnic baskets. Imagination without skill 
gives us modern art. -- Tom Stoppard
*/

-- 
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

RE: [PHP-DB] Database help needed

[Beau Lebens]

should be able to do something like

SELECT whatever FROM whereever WHERE value<='50' AND value>='45'

is that what you are looking for?

// -Original Message-
// From: Chris Payne [mailto:[EMAIL PROTECTED]]
// Sent: Thursday, 22 November 2001 3:11 PM
// To: [EMAIL PROTECTED]
// Subject: [PHP-DB] Database help needed
// 
// 
// Hi there everyone,
// 
// This may sound like an odd question and something that I 
// should know, but ...
// 
// I need to display results by amount - for example, for all 
// properties which are either or between 450,000 and 500,000 
// (For example) - how using PHP and MySQL do I get it to 
// display 450,000, 50,000 and all inbetween ???  I can easily 
// get it to display one or the other, but it is a search which 
// is based on cost of property.  How will I format the MySQL 
// query to get it to do this?
// 
// Please help a little english guy lost in the USA :-)
// 
// Thank you everyone, it's very appreciated.
// 
// Regards
// 
// Chris
// 
// www.planetoxygene.com
// 

-- 
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DB] Database help needed

[Chris Payne]

Hi there everyone,

This may sound like an odd question and something that I should know, but ...

I need to display results by amount - for example, for all properties which are either 
or between 450,000 and 500,000 (For example) - how using PHP and MySQL do I get it to 
display 450,000, 50,000 and all inbetween ???  I can easily get it to display one or 
the other, but it is a search which is based on cost of property.  How will I format 
the MySQL query to get it to do this?

Please help a little english guy lost in the USA :-)

Thank you everyone, it's very appreciated.

Regards

Chris

www.planetoxygene.com

[PHP-DB] Re: Problem with my Car DB

[Fred]

just add "LIMIT N,R" to your SELECT statement where N is the row you want to
start with and R is the number of rows you want to fetch.

The first row is 0 so if you want to fetch 10 cars per page make R 10 and
make N a variable.  Pass 0 to N on the first pass, then put links on your
page for NEXT where N=N+10

Fred

Lynn Geise <[EMAIL PROTECTED]> wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> Can someone give me the code to make the db display 10 cars per page then
> make another page with the links below the car for the next page youc na
see
> the car db here so far
> http://www.games-are-forever.com/phpadmin/cardisplay.php
>
>



-- 
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DB] Problem with my Car DB

[Lynn Geise]

Can someone give me the code to make the db display 10 cars per page then
make another page with the links below the car for the next page youc na see
the car db here so far
http://www.games-are-forever.com/phpadmin/cardisplay.php



-- 
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DB] Table Locking...

[Ashley M. Kirchner]

(PHP-DB folks, ignore this top question - unless you want to answer)

Which type of DB/Table provides table locking while a process is
altering data?  I don't care for locking while using SELECTs, but I do
need locking when something's being INSERTed or UPDATEd, so I won't get
two processes trying to do the same darned thing at the same time.



(MySQL folks, ignore this bottom question - unless you want to
answer)

I'm somewhat lost on how to do the following:

I'm trying to go through a table and check for a particular
information.  If it doesn't exist, then go ahead and issue an INSERT
with the relevant data.  The next time another process comes along,
it'll obviously find the information and issue an UPDATE instead.  But,
what happens if I get two processes running at the same time, trying to
find information that does not exist yet?

If both issue a SELECT and find the information not there, both will
try to issue an INSERT, where really I want one of those processes to
wait for the first one to finish doing whatever it needs to do, prior to
continuing.  (all of this is being done in PHP by the way).  Does anyone
have any suggestions for this scenario (or am I just blowing smoke out
my arse and there's something else, internally, that I'm not aware of?)
When (and how) to issue some sort of "wait" state for one process while
the other's finishing what it needs to do, then restart the second
process (which should re-check for existing information, and not blindly
issue another INSERT right after the first one).

--
W | I haven't lost my mind; it's backed up on tape somewhere.
  +
  Ashley M. Kirchner    .   303.442.6410 x130
  IT Director / SysAdmin / WebSmith . 800.441.3873 x130
  Photo Craft Laboratories, Inc.. 3550 Arapahoe Ave. #6
  http://www.pcraft.com . .  ..   Boulder, CO 80303, U.S.A.



-- 
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DB] Authenticate problem

[Harpreet]

Dear list members,

I have  login page which passes the user name to the next screen. If the
user is correct i want to direct him to the actual application. If not right
then i want to display a notlogged page. I am doing the following.
http://192.168.200.98/frame_main.htm";);
}
  else
{
 header("Location: http://192.168.200.98/notlogged.htm";);
}

It works fine if the user is right and takes the suer to the application.
But if i type in a user not allowed it gives me the following error and does
not direct to the notlogged page.

Warning: MySQL Connection Failed: Access denied for user:
'[EMAIL PROTECTED]' (Using password: NO) in /var/www/html/scripts/login.php
on line 4
Error on connection string.


How can i skip that message and send the user to the not logged page??

Please help.

Regards,
Harpreet Kaur
Software Developer
Crispin Corporations Inc.



-- 
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DB] unixODBC Question/Problem

[Eric Liedtke]

I am running PHP/Apache. I have installed unixODBC and inlinks tds 
driver. I can succesfully connect and query an MS SQL db from the isql 
command line testing tool provided with unixODBC. I recompiled php with 
unixODBC support and it compiled and installed without a problem. So it 
was onto writing the php. I can connect query and close the DB fine. 
However my query results always have 1 of 2 things. Either they are 
empty or the contain gibberish. At this point I don't know where to 
start troubleshooting the breakdown. Any help would be greatly 
appreciated. I don't know what info anyone might need from me, but will 
be more than happy to provide it. Thanks in advance.
Eric Liedtke

p.s. on a google search I found only one other mention of this in a 
dbforum website. sadly there were no replies to the posting there.


-- 
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DB] PostgreSql query help....

[GB Clark II]

On Monday 19 November 2001 20:27, Vincent Ma wrote:
> Hi everybody:
>
>   I would like to ask why the error occur when retrieve current sequence
> number.  Eg. "select currval('student_id_seq')" is not working, and warning
> prompt "student_id_seq.currval is not yet defined in this session".
>
> However, this is work for the "select nextval()";
>
> do anyone know how to get current sequence number, in php.  Thank for your
> help
>
> Vincent Ma
Hi,

The problem here is that it looks like you have NOT inserted a record into 
the DB yet, therefore, you don't have a current value to get. 

currval gets the last inserted id number for this connection.  nextval will 
get the value that will be used next.  

If you are trying to get a id number for insertion (i.e. not using the 
automatic insert) that nextval is the one you should use.

NOTE:  If you are using transactions and do a rollback, you will have holes 
in your sequences.


Hope this helps.

GB

-- 
GB Clark II | Roaming FreeBSD Admin
[EMAIL PROTECTED] | General Geek 
   CTHULU for President - Why choose the lesser of two evils?

-- 
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DB] Re: php/mysql error

[Fred]

The error indicates that the result resource is invalid.  The result
resource in your example is $rs.  Either this is not the variable that you
used when sending the query or something went wrong with the query.  You
should always add "or die(mysql_error) to the end of your mysql_query
statements, as it will give you a detailed message about what failed.

Fred

Jon <[EMAIL PROTECTED]> wrote in message Usenet.ipsiitnr@localhost">news:Usenet.ipsiitnr@localhost...
> please review my script
>
> I have already had it said that the script is fine, please check.  IF
> it is then I have a set up proiblem which I would also like help to
> solve. BUT mysql outside of apache works fine.
>
> I started with an already set up apache so I don't know if mysql was
> installed in right, but the staements before the error seem to work so
> I would think so.
>
> I running my web server under red hat 7.0, I am new to apache/php and
> mysql.
>
> Thanks
>
> 
>
> I get an error when it hits the line
>
> while ($row = mysql_fetch_row($rs)) {}
>
> I know it won't do anything, just checking each command.
>
> For a moment I thought this means that the mysql wan't compiled in but -
> then how comes the other mysql_ statements don't error.
>
> anyway the error I get is this
> Supplied argument is not a valid MySQL result resource ...
>
> Now I am a C++ programmer so I am estimating here, it sounds like $row -
> is wrong, do I need to set this up as an array (I believe that is what -
> it is supposed to be)
>
> The $rs is right I am pretty sure and the command should do what I want-
> it to do.
>
>
>
>
>



-- 
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DB] Intro to PEAR:DB

[Paul Meagher]

> >Now for the $15,000 question: does anyone else agree with this ? If
> >PEAR::DB is not abstracting the database what is the purpose of such a
> >library ?

I would suggest that Alexander's list of reasons for using PEAR:DB should
be written up in some introductory section to the manual for PEAR DB along
with some comment about the difference between a Unified DB and a Database
Abstraction Layer (based on some of Manual's remarks on the difference and
pointing to Metabase as an alternative for the latter).

> a) unifed API
> You havn't to think about the name of the command to send a query,
> connecting...

I agree.

I think it is a Unified API where a Unified API is defined as "a common
interface to connect to a db, execute queries, fetch the result and report
errors".

> b) it offers helpful functionality

> I.e. don't care about quoting and escaping in SQL-Statments, the query
command
> does it for you. PEAR:DB contains different possibilties to access the
result
> set... (Yes you can write such functions too, but why recreate the
wheel?)

I agree.

Where "helpful functionality" is defined as:

1.  Deals with quoting and escaping of SQL-Statements
2.  Provides different access methods for result sets
3.  Provides an array of error trapping and error reporting features for
debugging
4.  Provides higher level constructs for connecting to a db, issuing
queries, and accessing result sets
5.  Provides a studly caps API for connecting to a db, issuing queries, and
accessing result sets
6.  Add your own to this list

 > c) _helps_ to keep portability
> You have 'only' to change the SQL-statments, not the functions.

I agree again.  IMO, comments like these would be helpful in the intro to
PEAR: DB.

T Cox raises the point that we might be defining PEAR:DB into a corner
where all it really consists of are features that are useful to developers.
While I agree with that sentiment I also think it would be helpful if the
there were some explicit remarks about what PEAR:DB currently offers to the
web developer community.  Saying that it consists of features that are
useful to developers doesn't convey much to someone who is wondering
whether to use it or not - it is not an actionable comment.

At some point a long detailed article also needs to be written about what
portable database programming really consists off.  It would also be good
to have a FAQ that deals with some of the work arounds that you need to use
to deal with portability issues.  For example, what if you rely on the
autoincrementing feature in MySQL but Postgresql doesn't support it?  What
work around causes the least amount of reprogramming of db code when you
switch from using MySQL to PostgreSQL for example.

Regards,
Paul Meagher
>
> --
> PEAR Development Mailing List (http://pear.php.net/)
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> To contact the list administrators, e-mail: [EMAIL PROTECTED]
>
>


-- 
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DB] Re: [PEAR-DEV] Re: Common DB Abstraction Layer:

[Tomas V.V.Cox]

On Wednesday 21 November 2001 16:24, Joao Prado Maia wrote:
> On Wed, 21 Nov 2001, Martin Jansen wrote:
> > On Wed, 21 Nov 2001 09:19:44 -0500 (EST), Joao Prado Maia wrote:
> > >If PEAR::DB is not abstracting the database what is the purpose of
> > > such a library ?
> >
> > To ease the life of lot's of programmers.
>
> I probably used a bad choice of words. What I really meant was: What
> is the objective of PEAR::DB as a database abstraction library ? To
> abstract as much as possible like Metabase already does, or to
> provide a unified API to databases and leave the implementation
> related to database specific to the user himself ?
>
> It's okay to choose the latter, but I believe we should have a unique
> position on something like this, so we know what we are working for.
> A statement like this will be very helpful when people come to the
> mailing list saying that PEAR::DB doesn't abstract LOB's or any other
> exotic feature, as we can just reply "that's not our objective".
>

Personally I don't see the idea or position should be so strict. PEAR 
DB provides the things the users requested. I think there are no more 
things because there isn't a real need for them in common environment. 

About the discussion if PEAR DB abstracts the database or the API, what 
can I tell you, I use PEAR DB with Postgres, Mysql, ODBC (Navision, MS 
SQL, Access) with almost no portability problems. Only needs you to do 
the SQL work in a very standar way and sometimes use PHP code for some 
things.

If someone comes here saying: "hey I implemented this exotic feature 
for PEAR DB" I don't see the reason for dropping it only bacause is 
"not the objective". The only objective I see is that it has to be 
useful for the developers.


Tomas V.V.Cox

-- 
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DB] Newbie question - other way than insert statement?

[Daniel Schwab]

ok, thnx

> No, but SQL is your friend
*lol*

greez
daniel




-- 
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DB] Re: Common DB Abstraction Layer: Re: [PEAR-DEV] Adoption of Metabase

[l0t3k]

John,

  in addition to the list you posted, there's

- inconsistent/incomplete metadata support. it would be nice, for example if
the MySQL extension would be more
  precise about a field type than "string", etc

  i tried hard and failed to describe why i'd want to start a C based DB
library, and you have described the issues better than ive done in the past
weeks. im less particular on how things look at the PHP level (though i have
definite preferences), than to provide a general framework in C for
user-level code to build on. there are lots of issues not addressed or
handled in an ad-hoc way in the database extensions that have to be
addressed at a lower level, and doing so presents unique opportunities to
other module writers who need DB support in their extensions.

  i'll leave web developers to fight over flavors of ice-cream - i'm happy
to churn the milk.

l0t3k

BTW - i think i'll start using the term Unified API. seems Rorschach (sp?)
enough to please most folk.

John Lim <[EMAIL PROTECTED]> wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...

> Actually the common code is already available: it is the
> database extension API's. But most of the problems are
> in the database extension APIs also, and our work is fixing
> their mistakes.
>
> Examples:
> -Oracle ocifetchinto() returns OCI_ASSOC arrays in uppercase,
>  when everyone else is using lowercase.
>
> -Magic Quotes murders our quoting, and what about magic quotes
>  sybase which happens to be for interbase and sql server too!
>
> -Postgresql does not have an error number to return. And there is
>  no pg_insert_id() either.
>
> -Interbase's API is missing an arm and a leg, and whether it is
>  the left or right arm missing is not documented anywhere.
>
> -All extensions should support blobs like Oracle, with a fetch mode
>  that makes "SELECT blob FROM table" transparent with no special
>  coding.
>
> If we fixed these problems and more, we could talk about having
> a unified API. Otherwise for the Oracle OCI_ASSOC, I would prefer
> not to change it for speed, Manuel would want to provide an emulation
> layer, i would object because it's slow, etc...
>
>  John




-- 
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DB] Re: [PEAR-DEV] Re: Common DB Abstraction Layer: Re: [PEAR-DEV] Adoption of Metabase

[Pierre-Alain Joye]

> I probably used a bad choice of words. What I really meant was: What is
> the objective of PEAR::DB as a database abstraction library ? To abstract
> as much as possible like Metabase already does, or to provide a unified
> API to databases and leave the implementation related to database specific
> to the user himself ?
> 
> It's okay to choose the latter, but I believe we should have a unique
> position on something like this, so we know what we are working for. A
> statement like this will be very helpful when people come to the mailing
> list saying that PEAR::DB doesn't abstract LOB's or any other exotic
> feature, as we can just reply "that's not our objective".
I completly agree as an enduser point of view. :)

> Anyway, I think this is a good discussion.
Should we define this discussion as a brainstorming about PEAR:DB roadmap ? ;)

-- 
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DB] Re: Common DB Abstraction Layer: Re: [PEAR-DEV] Adoption of Metabase

[Pierre-Alain Joye]

On Wed, 21 Nov 2001 16:14:04 +0100 (MET)
Luc Saint-Elie <[EMAIL PROTECTED]> wrote:

> En réponse à Pierre-Alain Joye <[EMAIL PROTECTED]>:
> 
> 
> > This definition defines more a common interface to connect to a db,
> > execute queries, fetch the result and eventually gives errors reports
> > ;).
> 
> Somehow yes (do I still win the $15,000 ???)
:) christmast time soon... ;)

> I don't exactly agree.
> Of course most web developments with php use mySQL (or similar BD) so the 
> porting is a very light issue
> Of course, enterprise development (intranet, portals..) use other BD.. but the 
> porting is still a very light issue except if you company change very often its 
> licensing policy switching vendors back and forth ;- )
> So may be for your specific enterprise IT environment PEAR::BD right now 
> doesn't fit your needs.. fine.. some day hope this will change, but its more 
> a "do you support DB XX ?" issue than a "are you cross DB ?" one.
If you develop a complete application (a KMS by example), you will like to create a 
standart version that you don't have to customize. Customer A uses Oracle, B uses 
Sybase and C uses SQLserver, the best way for the connectivity part is real 
abstraction layer whatever you use for the application itself. You don't have to 
create new queries, stored procs and so on, every times you ve got a new rdmbs to work 
with.
For your internal application needs, effectivly you will not change BD every day, and 
as far you respect SQL standarts, it's not a great jobs to move.


> The result is that the question (IMHO) is more a "is it possible to adapt 
> PEAR::DB to my specific case ?" (been at risk that the answer is "no") 
> than "how could we start from the beginning to build something else?"
The wheel ? ;)

pa

-- 
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DB] Re: [PEAR-DEV] Re: Common DB Abstraction Layer: Re: [PEAR-DEV]Adoption of Metabase

[Joao Prado Maia]

On Wed, 21 Nov 2001, Martin Jansen wrote:

> On Wed, 21 Nov 2001 09:19:44 -0500 (EST), Joao Prado Maia wrote:
>
> >If PEAR::DB is not abstracting the database what is the purpose of such a
> >library ?
>
> To ease the life of lot's of programmers.
>

I probably used a bad choice of words. What I really meant was: What is
the objective of PEAR::DB as a database abstraction library ? To abstract
as much as possible like Metabase already does, or to provide a unified
API to databases and leave the implementation related to database specific
to the user himself ?

It's okay to choose the latter, but I believe we should have a unique
position on something like this, so we know what we are working for. A
statement like this will be very helpful when people come to the mailing
list saying that PEAR::DB doesn't abstract LOB's or any other exotic
feature, as we can just reply "that's not our objective".

Anyway, I think this is a good discussion.

Joao

--
João Prado Maia <[EMAIL PROTECTED]>
http://phpbrasil.com - php com um jeitinho brasileiro
--
Precisando de consultoria em desenvolvimento para a Internet ?
Impleo.net - http://impleo.net/?lang=br


--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DB] problems with mysql_close inside classes and functions

[Matthias Pretzer]

Hi there,

we use a wrapper class to access a mysql db with php-4.0.6 running in
Apache/Linux and mysql-3.23.40.

We ran into the following problem:

Assume the following test code (sorry - rather long):


-[ test code ]--

reader,$this->writer);

( $this->writer = mysql_connect($DB_M_server, $DB_M_user, $DB_M_pass) 
) || die ("Konnte keine Verbindung zum Master herstellen!");
mysql_select_db($DB_M_dbase, $this->writer) || die ("Konnte Master-DB 
nicht auswaehlen!");

( $this->reader = mysql_connect($DB_S_server, $DB_S_user, $DB_S_pass) 
) || die ("Konnte keine Verbindung zum Reader herstellen!");
mysql_select_db($DB_S_dbase, $this->reader) || die ("Konnte Reader-DB 
nicht auswaehlen!");

$this->reader_rs = "";
$this->reader_nr = "";

$this->writer_rs = "";
$this->writer_li = "";
$this->writer_ar = "";
}

function close () {
// Verbindung kappen
mysql_close($this->writer);
mysql_close($this->reader);
unset($this->writer);
unset($this->reader);
}

function read ($SQL) {
// Von den Slaves lesen, Anzahl der Zeilen im Result Set festhalten
if ($SQL != "") {
// Wenn wir grade _nicht_ in einer Transaktion sind, vom 
Reader lesen
if ($this->writer_transaction != 1) {
$this->reader_rs = mysql_query($SQL, $this->reader);
if (! $this->reader_rs) return FALSE;
$this->reader_nr = mysql_num_rows($this->reader_rs);
return TRUE;
} else {
// Innerhalb einer Transaktion vom Writer lesen, nur 
der kann da die richtigen
// Daten haben. Das Result Set wird trotzdem in 
$this->reader_rs gespeichert, damit
// die weiteren Zugriffsfunktionen dann auch innerhalb 
der Transaktion funktionieren
$this->reader_rs = mysql_query($SQL, $this->writer);
if (! $this->reader_rs) return FALSE;
$this->reader_nr = mysql_num_rows($this->reader_rs);
return TRUE;
}
} else {
$this->reader_rs = "";
$this->reader_nr = "";
return FALSE;
}
}

function get () {
// Zeile aus dem aktuellen Result Set holen
return mysql_fetch_array($this->reader_rs);
}

} //class

function bla() {

$db2 = new NWN_DB;

print "reader_f: " . $db2->reader."";
print "writer_f: " . $db2->writer."";

$sql = "SELECT * FROM bookmarks";
$db2->read($sql);
echo "table bookmarks ";
while($tmp = $db2->get()) {
echo "db2 : $tmp[0] ";
}
$db2->close();
//if you omit this close(), $db3 will later get the same connection
//as db and db2
}


//lets go
$db = new NWN_DB;

print "reader1: " . $db->reader."";
print "writer1: " . $db->writer."";

$sql = "SELECT * FROM profile";
$db->read($sql);

bla(); //establishes the second db connection


/*
 $db3 will get a new ressource id if bla() closes its connection
 although the link is still in use by $db
 --> conclusion: the reference count for the db link does not work somehow
 probably this is related to the use of a class for the db connections
*/
$db3 = new NWN_DB;
$db3->read("SELECT * FROM mpr_attributes");

print "reader3: " . $db3->reader."";
print "writer3: " . $db3->writer."";

echo "table mpr_attributes ";
while($tmp = $db3->get()) {
echo "db3 : $tmp[0] ";
}

$db3->close();

//this still returns the correct results
//although the last $db->close() tells us
//there is no more mysql connection available
echo "table profile ";
while($tmp = $db->get()) {
echo "db : $tmp[0] ";
}

print "reader_a: " . $db->reader."";
print "writer_a: " . $db->writer."";

$db->close();



print "end object stuff ";


function bla2() {
global $DB_M_server, $DB_M_user, $DB_M_pass, $DB_M_dbase;

$conn2 = mysql_connect($DB_M_server, $DB_M_user, $DB_M_pass);
mysql_select_db($DB_M_dbase,$conn2);
$rs = mysql_query("SELECT * FROM mpr_attributes",$conn2);

echo "resource2: $conn2 ";

while ($tmp = mysql_fetch_row($rs)) {
print "conn2: $tmp[0] ";
}
mysql_close($conn2);

}


$conn = mysql_connect($D

[PHP-DB] Re: Common DB Abstraction Layer: Re: [PEAR-DEV] Adoption of Metabase

[Luc Saint-Elie]

En réponse à Pierre-Alain Joye <[EMAIL PROTECTED]>:


> This definition defines more a common interface to connect to a db,
> execute queries, fetch the result and eventually gives errors reports
> ;).

Somehow yes (do I still win the $15,000 ???)

> IMO, the need of a real abstraction layer is not a must for the majority
> of php endusers. In another view, it will give to php tools for projects
> who use actually others systems (MS asp, j2ee,...).
> Most of pure web developments don't need a real abst. layer, intranet
> portails or enterprise tools need.

I don't exactly agree.
Of course most web developments with php use mySQL (or similar BD) so the 
porting is a very light issue
Of course, enterprise development (intranet, portals..) use other BD.. but the 
porting is still a very light issue except if you company change very often its 
licensing policy switching vendors back and forth ;- )

So may be for your specific enterprise IT environment PEAR::BD right now 
doesn't fit your needs.. fine.. some day hope this will change, but its more 
a "do you support DB XX ?" issue than a "are you cross DB ?" one.

The result is that the question (IMHO) is more a "is it possible to adapt 
PEAR::DB to my specific case ?" (been at risk that the answer is "no") 
than "how could we start from the beginning to build something else?"

Luc

-- 
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DB] Checking inserts

[Russ Michell]

Hi all:

I'm wondering what you guys use as your 'standard' method of checking for repeated 
inserts. (as 
opposed to having to cane the database with a 'select' statement when a check needs to 
be 
made..)

I think I have to use mysql_affected_rows() and/or mysql_insert_id(), unfortunately I 
don't see how 
these might do the job. Any help or pointers to web-resources would be most helpful!

If useful, I'm using the old fella: MySQL3.22.32

Cheers all.
Russ

#---#

  "Believe nothing - consider everything"   
  
  Russ Michell
  Anglia Polytechnic University Webteam
  Room 1C 'The Eastings' East Road, Cambridge
  
  e: [EMAIL PROTECTED]
  w: www.apu.ac.uk/webteam

  www.theruss.com

#---#


-- 
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DB] Re: [PEAR-DEV] Re: Common DB Abstraction Layer: Re: [PEAR-DEV] Adoption of Metabase

[Pierre-Alain Joye]

> Well I strongly need thoses $15 000 $ so 
> 
> What is the purpose ?
> As a "average php user/developper" I don_t really care about the "pure cross 
> plateform/database issue"  but I do care about a standard, clean, secure ("my-
> bugs-free") and easy way to use a database, and PEAR::BD + Thomas V Cox 
> tutorial are under this aspect real time savers...
> 
> So the purpose is "ease my life"...
This definition defines more a common interface to connect to a db, execute queries, 
fetch the result and eventually gives errors reports ;).

IMO, the need of a real abstraction layer is not a must for the majority of php 
endusers. In another view, it will give to php tools for projects who use actually 
others systems (MS asp, j2ee,...).
Most of pure web developments don't need a real abst. layer, intranet portails or 
enterprise tools need.

Maybe we need a simple unified api and a "real" (imho impossible to do a real one)  
abstraction layer ? (the unified api should be only a wrapper)

pa

-- 
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DB] Persistent Connections

[Joshua Hoover]

According to the docs and everything I've seen with PHP and persistent 
connections, you don't have to close the connection since PHP will 
simply reuse.

Joshua Hoover

> Howdy--I have a question about persistent connections and their 
> behavior:
>
> Apache 1.3.2 / PHP 4.0.6 - as a module
> Win2k
>
> I call the following function:
>
> odbc_pconnect("dsn", "user", "pass");
>
> At the end of the script I do NOT call odbc_close($dbConn);
>
> I was doing some testing and ran into a:
>
> Maximum number of processes exceeded etc.. etc.. etc..
>
> This is in relation to the persistent connections.  Now the question 
> is, does ODBC_CLOSE really close the connection?  Or another way of 
> asking is, does ODBC_PCONNECT look for a use an existing connection, or 
> does it launch another one?
>
> Should I close the connection and not worry about it?
> Thanks
> RDB


-- 
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DB] Re: [PEAR-DEV] Re: Common DB Abstraction Layer: Re: [PEAR-DEV] Adoption of Metabase

[Alexander Merz]

>Now for the $15,000 question: does anyone else agree with this ? If
>PEAR::DB is not abstracting the database what is the purpose of such a
>library ?
a) unifed API
You havn't to think about the name of the command to send a query,
connecting...

b) it offers helpful functionality
I.e. don't care about quoting and escaping in SQL-Statments, the query command
does it for you. PEAR:DB contains different possibilties to access the result
set... (Yes you can write such functions too, but why recreate the wheel?)

c) _helps_ to keep portability
You have 'only' to change the SQL-statments, not the functions.


-- 
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DB] Re: Common DB Abstraction Layer:

[Tomas V.V.Cox]

Manuel Lemos wrote:
> 
> Hello,
> 
> John Lim wrote:
> > Each designer has a different point of view, like Tomas has
> > written a really excellent oci8 "select limit" emulation, but looking
> > at the code, it's so complicated that i decided not to incorporate it
> > in ADODB because I value simplicity. I know Tomas' code works
> > in theory, and its really impressive that you even considered UNIONs,
> > Tomas, but I just like "simple" code that I can keep in my head.
> 
> But it does not work with computed columns like those that apply
> functions (COUNT, SUM, SUBSTRING, etc...). The code assumes that you are
> actually selecting only real table fields. I think it also does not work
> with columns with table name prefixes.

That's partially true. But it's a common practise to use column aliases
in conyunction with functions (and a must for assoc fetchs) and this is
supported by the code I wrote, for ex:

select count(field) as count from foo;

Also if Oracle name a sum(foo) column as "sum" will be trivial to add
it.

Any way I said it later, a real SQL parser will be the solution. Stig
came with the idea time ago and nowadays it will help a lot in many
other cases.


Tomas V.V.Cox

-- 
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DB] Re: Common DB Abstraction Layer: Re: [PEAR-DEV] Adoption of Metabase

[Luc Saint-Elie]

En réponse à Joao Prado Maia <[EMAIL PROTECTED]>:


> Now for the $15,000 question: does anyone else agree with this ? If
> PEAR::DB is not abstracting the database what is the purpose of such a
> library ?

Well I strongly need thoses $15 000 $ so 

What is the purpose ?
As a "average php user/developper" I don’t really care about the "pure cross 
plateform/database issue"  but I do care about a standard, clean, secure ("my-
bugs-free") and easy way to use a database, and PEAR::BD + Thomas V Cox 
tutorial are under this aspect real time savers...

So the purpose is "ease my life"...

Well we’ll discuss privately about money transfert

Luc

-- 
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DB] Re: Common DB Abstraction Layer

[Tomas V.V.Cox]

John Lim wrote:

Hi John,

> 
> >
> > The only exit I see of the multi abstraction layers problems is trying
> > to join all those communities and start a new development from the
> > ground. The code is almost all written so only need to glue it to meet
> > the specs of the new resultant layer. Then each team could provide
> > their own wrappers to make things easy to their users. That's IMO a
> > cooperative behaviour.
> >
> > Tomas V.V.Cox
> 
> Hi Tomas, Manuel, everyone,
> 
> I think that different programmers have different needs.
> Metabase's goal is 100% DB portability. PEAR DB builds on the
> PEAR classes to give a solid set of classes. ADODB is aimed
> at converting the heathen ASP'ers to the "one true religion".
> I also know of a PHP DBI class also from people who still need
> the $perl~= /fix/;

All the things you say here could be the features of a new abstraction
layer done by a high experimented team. The point is to relax a little
our obsessions.

 
> Each designer has a different point of view, like Tomas has
> written a really excellent oci8 "select limit" emulation, but looking
> at the code, it's so complicated that i decided not to incorporate it
> in ADODB because I value simplicity. I know Tomas' code works
> in theory, and its really impressive that you even considered UNIONs,
> Tomas, but I just like "simple" code that I can keep in my head.

Thanks for the kind words :-). I know it's a little bit obscure cause I
needed to implement part of a SQL parser, but with more resources in a
supposed union we could develop a real SQL parser and in the case of the
row limit for Oracle the code needed will be reduced to two method
calls.
 
> I think some standardization in terms of API is good, but I don't
> think most people care. Newcomers to programming will want to use
> something easy and "standard" - is PEAR DB already the standard?
> Windows programmers would want to use something familar. I already
> have a prototype PEAR DB api wrapper for ADODB , and ADODB has
> support for PEAR Error() also, but the people who like ADODB
> generally are not that interested (at the moment).

They don't want automatic error handling? Uff, I couldn't live with it
;)
 
> > to join all those communities and start a new development from the
> > ground. The code is almost all written so only need to glue it to meet
> > the specs of the new resultant layer.
> 
> Actually the common code is already available: it is the
> database extension API's. But most of the problems are
> in the database extension APIs also, and our work is fixing
> their mistakes.
> 
> Examples:
> -Oracle ocifetchinto() returns OCI_ASSOC arrays in uppercase,
>  when everyone else is using lowercase.

>From PEAR we requested the native C PHP function to change the case of
the key of the resultant array and the waste of exec time is almost
null. This function will be avaible in 4.1 (I guess) and in the PEAR DB
that will come with it (I hope).
 
> -Magic Quotes murders our quoting, and what about magic quotes
>  sybase which happens to be for interbase and sql server too!

Yeah, magic_quotes_* are evil and they should be off by default. Anyone
with enought karma can do that? :-P

> -Postgresql does not have an error number to return. And there is
>  no pg_insert_id() either.

The error numbers is a PHP API problem or Postgres API one? PHP would
suck a lot if that is supported but not used, knowing that the Postgres
guys change the error messages in each release.

About the pg_insert_id(), Postgres have native support for sequences IMO
the real way to do that kind of things.
 
> -Interbase's API is missing an arm and a leg, and whether it is
>  the left or right arm missing is not documented anywhere.

That's true. I used Interbase time ago and was very robust, also now is
Open Source and is a backend with the features of Postgres and the speed
of MySQL. The lack of a good PHP support is limiting it's use for sure.
Well, a DB with some backdoors but they are being closed ;).
 
> -All extensions should support blobs like Oracle, with a fetch mode
>  that makes "SELECT blob FROM table" transparent with no special
>  coding.

I don't use them, can't say anything on that.
 
> If we fixed these problems and more, we could talk about having
> a unified API. Otherwise for the Oracle OCI_ASSOC, I would prefer
> not to change it for speed, Manuel would want to provide an emulation
> layer, i would object because it's slow, etc...
> 

That's solved (see above) :-)


Tomas V.V.Cox

-- 
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DB] Re: [PEAR-DEV] Re: Common DB Abstraction Layer: Re: [PEAR-DEV] Adoption of Metabase

[Pierre-Alain Joye]

On Wed, 21 Nov 2001 09:19:44 -0500 (EST)
Joao Prado Maia <[EMAIL PROTECTED]> wrote:

> 
> On Wed, 21 Nov 2001, Manuel Lemos wrote:
> 
> > > If we fixed these problems and more, we could talk about having
> > > a unified API. Otherwise for the Oracle OCI_ASSOC, I would prefer
> > > not to change it for speed, Manuel would want to provide an emulation
> > > layer, i would object because it's slow, etc...
> >
> > If you want to resort to non-portable database programming, just stick
> > with the native database API that PHP offers and you will get all the
> > speed that is possible. Using a database abstraction that does not offer
> > portability and still adds execution overhead does not make much sense.
> > Your programs still need to be adapted to run with different databases
> > and they will still be slower than using the native PHP database APIs.
> >
> 
> Just for the record, I agree 100% with Manuel on this one.
> 
> Now for the $15,000 question: does anyone else agree with this ? If
> PEAR::DB is not abstracting the database what is the purpose of such a
> library ?
I asked that in a past thread, manuel answer something quit explicit and correct. 
Trying to find it back. :)

pa

-- 
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DB] Re: [PEAR-DEV] Re: Common DB Abstraction Layer: Re: [PEAR-DEV] Adoption of Metabase

[Martin Jansen]

On Wed, 21 Nov 2001 09:19:44 -0500 (EST), Joao Prado Maia wrote:

>If PEAR::DB is not abstracting the database what is the purpose of such a
>library ?

To ease the life of lot's of programmers.

- Martin



-- 
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DB] Need Help on "DHTML and PHP"

[MrBaseball34]

> >  I wrote a program which retrieved Username from DB every 2 or 4=
>  second.

Why every 2 or 4 seconds do you need to retrieve the username? The user is 
still the same in the session...

-- 
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DB] Re: [PEAR-DEV] Re: Common DB Abstraction Layer: Re: [PEAR-DEV]Adoption of Metabase

[Joao Prado Maia]

On Wed, 21 Nov 2001, Manuel Lemos wrote:

> > If we fixed these problems and more, we could talk about having
> > a unified API. Otherwise for the Oracle OCI_ASSOC, I would prefer
> > not to change it for speed, Manuel would want to provide an emulation
> > layer, i would object because it's slow, etc...
>
> If you want to resort to non-portable database programming, just stick
> with the native database API that PHP offers and you will get all the
> speed that is possible. Using a database abstraction that does not offer
> portability and still adds execution overhead does not make much sense.
> Your programs still need to be adapted to run with different databases
> and they will still be slower than using the native PHP database APIs.
>

Just for the record, I agree 100% with Manuel on this one.

Now for the $15,000 question: does anyone else agree with this ? If
PEAR::DB is not abstracting the database what is the purpose of such a
library ?

Cheers,
Joao

--
João Prado Maia <[EMAIL PROTECTED]>
http://phpbrasil.com - php com um jeitinho brasileiro
--
Precisando de consultoria em desenvolvimento para a Internet ?
Impleo.net - http://impleo.net/?lang=br


--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DB] Re: Newbie Question

[Lee Willmann]

Ok, I think I have the solution to your problem.

Try using nl2br() on the data in that field..
Example:

I have a message table that allows one user to send an instant message to
another user on my site. There are several fields, one of which being a TEXT
column (MySQL db). I use a simple textarea form element to get the data. It
inserts into the DB as basically a single line regardless of the ENTER
keystrokes in the data. Now, when I pull it back out I use this:

$query = "SELECT * FROM message WHERE msg_id = '$msg_id'";
$query_result = mysql_query($query);
$query_row = mysql_fetch_array($query_result);

$message = $query_row["message"];

echo "Message text:".nl2br($message);

And that should do what you need.

Lee Willmann

"Steve Brett" <[EMAIL PROTECTED]> wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> have a look at get_html_translation_table() in the php manual.
>
> there is an example of conversion of all special chars so they can be
> inserted into the database as text (i.e. £>£) and a cool way of
> 'decoding' them if you need to write them to a file. A Browser wil
interpret
> them correctly when they are displayed.
>
> This must be the question of the day as i have posted this answer three
> times today :-)
>
> Let me know if you need any more help
>
> Steve
>
> get_html_translation_table manual page is below:
>
>   PHP Manual
>   Prev  Next
>
> --
--
> 
>
> get_html_translation_table
> (PHP 4 >= 4.0b4)
>
> get_html_translation_table --  Returns the translation table used by
> htmlspecialchars() and htmlentities()
> Description
>
> string get_html_translation_table (int table [, int quote_style])
>
>
> get_html_translation_table() will return the translation table that is
used
> internally for htmlspecialchars() and htmlentities(). There are two new
> defines (HTML_ENTITIES, HTML_SPECIALCHARS) that allow you to specify the
> table you want. And as in the htmlspecialchars() and htmlentities()
> functions you can optionally specify the quote_style you are working with.
> The default is ENT_COMPAT mode. See the description of these modes in
> htmlspecialchars(). Example 1. Translation Table Example
>
> $trans = get_html_translation_table (HTML_ENTITIES);
> $str = "Hallo &  & Krämer";
> $encoded = strtr ($str, $trans);
>
>
>
> The $encoded variable will now contain: "Hallo &  &
> Krämer".
>
> The cool thing is using array_flip() to change the direction of the
> translation.
>
>
> $trans = array_flip ($trans);
> $original = strtr ($str, $trans);
>
>
>
>
> The content of $original would be: "Hallo &  & Krämer".
>   Note: This function was added in PHP 4.0.
>
>
> See also: htmlspecialchars(), htmlentities(), strtr(), and array_flip().
>
>
> --
--
> 
>   Prev Home Next
>   explode Up get_meta_tags
>
>
>
>
>
> "Jay Fitzgerald" <[EMAIL PROTECTED]> wrote in message
> [EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> > Ok, I am still fairly new at PHP and MySQL also, so please bear with me.
> >
> >
> > TASK: I have a client that wants to have job openings listed on their
site
> > and they want to be able to add, edit and delete the postings
themselves.
> I
> > would do this in flat-file format but there is the risk of that file
size
> > getting too large and slowing down the server.
> >
> >
> > SOLUTION: I have created a MySQL database that will hold all the
postings
> > in a table called 'jobs' and have created a PHP form that will post this
> > jobs into the db.
> >
> > PROBLEM: When I go to the PHP form and enter all of the pertinent job
> > information, there is one specific field that will have to have carriage
> > returns/line breaks in it between paragraphs. Everything is working
except
> > for this. Is there a way whenever the user presses , that either
> > PHP/MySQL will convert this into a  tag only when being displayed in
a
> > browser and not in the db??
> >
> >
> > Can anyone out there please help me with this? I am available off-list
as
> > well if it will be easier to pass code back and forth. Any assistance is
> > greatly appreciated!
> >
> >
> >
> > Should you have any questions, comments or concerns, feel free to call
me
> > at 318-338-2034.
> >
> > Thank you for your time,
> >
> > Jay Fitzgerald, Design Director - CSBW-A, CPW-A, CWD-A, CEMS-A
> > ==
> > Bayou Internet..(888)
> > 30-BAYOUhttp://www.bayou.com
> > Mississippi Internet...(800)
> > MISSISSIPPI...http://www.mississippi.net
> > Vicksburg Online..(800)
> > MISSISSIPPIhttp://www.vicksburg.com
> > ==
> > Tel: (318) 338-2034ICQ: 38823829
Fax:
> > (318) 323-5053
> >
>
>



-- 
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, e-mail: [E

[PHP-DB] Connecting MSSQL with PHP

[leela devi]

Hai Group,
I'am to new PHP and I'am struck with connecting to
MSSQL . I'am using PHP 4.0.6, PWS with MSSQL Server
7.0.  I've followed the instructions given in the
configuration file that came with the software. I've
copied php_mssql.dll into my windows directory and it
is there in the directory where my PHP is running. Is
there anything like compiling PHP to using MSSQL? Is
there anybody to help me out please?

thanx,
Leels.

__
Do You Yahoo!?
Yahoo! GeoCities - quick and easy web site hosting, just $8.95/month.
http://geocities.yahoo.com/ps/info1

-- 
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]