CodeCharge Studio
search Register Login  

Visual PHP Web Development

Visually Create Internationalized Web Applications, Web Reports, Calendars, and more.
CodeCharge.com

YesSoftware Forums -> Archive -> CodeCharge.Discussion

 Move out the connection info for PHP into a seperate file.

Print topic Send  topic

Author Message
Jeff Stuart
Posted: 04/26/2001, 12:05 PM

Ok... here's another suggestion:

Currently, you store the connection parameters for a database in common.php.
Rather than doing that, move that OUT of common.php into another file. This
way, we can upload the files to our production server, edit the new file
once to look at our production database, and still keep regenning common.php
as we want to.

Or, I wonder... would this work with a custom connection stuff? Hmm...

--
Jeff Stuart
jstuart@neo.rr.com


CodeCharge
Posted: 04/26/2001, 10:14 PM

> Rather than doing that, move that OUT of common.php into another file.

Common.php is already that another file.
There is no other purpose to Common.php but to store common settings and
functions.
If we generated the connection string to a different file, you'd arrive at
the same situation.

> This
> way, we can upload the files to our production server, edit the new file
> once to look at our production database, and still keep regenning
common.php
> as we want to.

If you select Local/Network location in Publishing properties and then
specify your database name in the Databas properties, it is kept separately
from your FTP database settings. Basically, you can create 2 database
profiles, one for your local server, and one for the ftp location.



"Jeff Stuart" <jstuart-devel@neo.rr.com> wrote in message
news:9c9rgs$1gg$1@mail.tankhill.com...
> Ok... here's another suggestion:
>
> Currently, you store the connection parameters for a database in
common.php.
> Rather than doing that, move that OUT of common.php into another file.
This
> way, we can upload the files to our production server, edit the new file
> once to look at our production database, and still keep regenning
common.php
> as we want to.
>
> Or, I wonder... would this work with a custom connection stuff? Hmm...
>
> --
> Jeff Stuart
>jstuart@neo.rr.com
>
>
>

Jeff Stuart
Posted: 04/26/2001, 10:29 PM

What I meant was that you have the following code in common.php:

//-- handling database connection
include("./db_mysql.inc");

define("DATABASE_NAME","");
define("DATABASE_USER","");
define("DATABASE_PASSWORD","");
define("DATABASE_HOST","");

//-- Database class
$db = new DB_Sql();
$db->Database = DATABASE_NAME;
$db->User = DATABASE_USER;
$db->Password = DATABASE_PASSWORD;
$db->Host = DATABASE_HOST;

and since this is going into an existing PHPLib enabled server, I already
have my db classes... SO.. what I was HOPING to be able to do was change the
new DB_Sql to new DB_Wod (which is the name of my db).

Turns out if I use the custom connections thingie, I get this:

$db = new DB_Wod();

which does EXACTLY what I want. :) So you guys have already anticipated my
needs... :)


--
Jeff Stuart
jstuart@neo.rr.com

"CodeCharge" <support@codecharge.com> wrote in message
news:9cav7g$1ub$1@mail.tankhill.com...
> > Rather than doing that, move that OUT of common.php into another file.
>
> Common.php is already that another file.
> There is no other purpose to Common.php but to store common settings and
> functions.
> If we generated the connection string to a different file, you'd arrive at
> the same situation.
>
> > This
> > way, we can upload the files to our production server, edit the new file
> > once to look at our production database, and still keep regenning
> common.php
> > as we want to.
>
> If you select Local/Network location in Publishing properties and then
> specify your database name in the Databas properties, it is kept
separately
> from your FTP database settings. Basically, you can create 2 database
> profiles, one for your local server, and one for the ftp location.
>
>
>
> "Jeff Stuart" <jstuart-devel@neo.rr.com> wrote in message
>news:9c9rgs$1gg$1@mail.tankhill.com...
> > Ok... here's another suggestion:
> >
> > Currently, you store the connection parameters for a database in
> common.php.
> > Rather than doing that, move that OUT of common.php into another file.
> This
> > way, we can upload the files to our production server, edit the new file
> > once to look at our production database, and still keep regenning
> common.php
> > as we want to.
> >
> > Or, I wonder... would this work with a custom connection stuff? Hmm...
> >
> > --
> > Jeff Stuart
> >jstuart@neo.rr.com
> >
> >
> >
>
>

CodeCharge
Posted: 04/26/2001, 10:41 PM

OK Jeff. But you can modify common.php and keep it the way you want it, just
like you would the "other file".
I'm still not sure if anything would change by generating the db settings to
another file. The another file would become equivalent to "common.php" and
we'd be where we started :)

Adam S.
CodeCharge Support

"Jeff Stuart" <jstuart-devel@neo.rr.com> wrote in message
news:9cb046$3df$1@mail.tankhill.com...
> What I meant was that you have the following code in common.php:
>
> file://-- handling database connection
> include("./db_mysql.inc");
>
> define("DATABASE_NAME","");
> define("DATABASE_USER","");
> define("DATABASE_PASSWORD","");
> define("DATABASE_HOST","");
>
> file://-- Database class
> $db = new DB_Sql();
> $db->Database = DATABASE_NAME;
> $db->User = DATABASE_USER;
> $db->Password = DATABASE_PASSWORD;
> $db->Host = DATABASE_HOST;
>
> and since this is going into an existing PHPLib enabled server, I already
> have my db classes... SO.. what I was HOPING to be able to do was change
the
> new DB_Sql to new DB_Wod (which is the name of my db).
>
> Turns out if I use the custom connections thingie, I get this:
>
> $db = new DB_Wod();
>
> which does EXACTLY what I want. :) So you guys have already anticipated
my
> needs... :)
>
>
> --
> Jeff Stuart
>jstuart@neo.rr.com
>
> "CodeCharge" <support@codecharge.com> wrote in message
>news:9cav7g$1ub$1@mail.tankhill.com...
> > > Rather than doing that, move that OUT of common.php into another file.
> >
> > Common.php is already that another file.
> > There is no other purpose to Common.php but to store common settings and
> > functions.
> > If we generated the connection string to a different file, you'd arrive
at
> > the same situation.
> >
> > > This
> > > way, we can upload the files to our production server, edit the new
file
> > > once to look at our production database, and still keep regenning
> > common.php
> > > as we want to.
> >
> > If you select Local/Network location in Publishing properties and then
> > specify your database name in the Databas properties, it is kept
> separately
> > from your FTP database settings. Basically, you can create 2 database
> > profiles, one for your local server, and one for the ftp location.
> >
> >
> >
> > "Jeff Stuart" <jstuart-devel@neo.rr.com> wrote in message
> >news:9c9rgs$1gg$1@mail.tankhill.com...
> > > Ok... here's another suggestion:
> > >
> > > Currently, you store the connection parameters for a database in
> > common.php.
> > > Rather than doing that, move that OUT of common.php into another file.
> > This
> > > way, we can upload the files to our production server, edit the new
file
> > > once to look at our production database, and still keep regenning
> > common.php
> > > as we want to.
> > >
> > > Or, I wonder... would this work with a custom connection stuff?
Hmm...
> > >
> > > --
> > > Jeff Stuart
> > >jstuart@neo.rr.com
> > >
> > >
> > >
> >
> >
>
>

Jeff Stuart
Posted: 04/27/2001, 8:07 AM

Yes BUT.. Let me explain my work flow and maybe it'll make more sense.



I run codecharge here on my local workstation (where I'm typing this
response).

I have another machine right next to me running Linux, Mysql, Apache, and
PHP which is my devel server. All of my codecharge generated files go
there. Also, when I FIRST setup a new codecharge project, I point the DB to
my devel server.

I have remote FTP server which is the actual production server. As I test
things, I upload each of the files up to the production server so that they
can be used. In the process, I modify the common.php after I upload it so
that it points to the PRODUCTION DB server which of course is NOT my devel
server.



Now, say I come back a day or so later and add a global module? Well, it
rewrites common.php! Now IF it had a separate file that you included (call
it db_conn.inc) which ALL it had was this:



define("DATABASE_NAME","");

define("DATABASE_USER","");

define("DATABASE_PASSWORD","");

define("DATABASE_HOST","");



Then I wouldn't lose my changes after I uploaded common.php up to the
production server.



NOW. FOR ME. I've worked around this. I've already got PHPLib installed on
the production server and therefore already have DB_Sql subclassed into my
own DB setup. Therefore. ALL I do is just setup a custom connection and my
problem is solved. J



I may be different than most other folks. Don't know. J


--
Jeff Stuart
jstuart@neo.rr.com

"CodeCharge" <support@codecharge.com> wrote in message
news:9cb0qn$4pt$1@mail.tankhill.com...
> OK Jeff. But you can modify common.php and keep it the way you want it,
just
> like you would the "other file".
> I'm still not sure if anything would change by generating the db settings
to
> another file. The another file would become equivalent to "common.php" and
> we'd be where we started :)
>
> Adam S.
> CodeCharge Support
>
> "Jeff Stuart" <jstuart-devel@neo.rr.com> wrote in message
>news:9cb046$3df$1@mail.tankhill.com...
> > What I meant was that you have the following code in common.php:
> >
> > file://-- handling database connection
> > include("./db_mysql.inc");
> >
> > define("DATABASE_NAME","");
> > define("DATABASE_USER","");
> > define("DATABASE_PASSWORD","");
> > define("DATABASE_HOST","");
> >
> > file://-- Database class
> > $db = new DB_Sql();
> > $db->Database = DATABASE_NAME;
> > $db->User = DATABASE_USER;
> > $db->Password = DATABASE_PASSWORD;
> > $db->Host = DATABASE_HOST;
> >
> > and since this is going into an existing PHPLib enabled server, I
already
> > have my db classes... SO.. what I was HOPING to be able to do was change
> the
> > new DB_Sql to new DB_Wod (which is the name of my db).
> >
> > Turns out if I use the custom connections thingie, I get this:
> >
> > $db = new DB_Wod();
> >
> > which does EXACTLY what I want. :) So you guys have already anticipated
> my
> > needs... :)
> >
> >
> > --
> > Jeff Stuart
> >jstuart@neo.rr.com
> >
> > "CodeCharge" <support@codecharge.com> wrote in message
> >news:9cav7g$1ub$1@mail.tankhill.com...
> > > > Rather than doing that, move that OUT of common.php into another
file.
> > >
> > > Common.php is already that another file.
> > > There is no other purpose to Common.php but to store common settings
and
> > > functions.
> > > If we generated the connection string to a different file, you'd
arrive
> at
> > > the same situation.
> > >
> > > > This
> > > > way, we can upload the files to our production server, edit the new
> file
> > > > once to look at our production database, and still keep regenning
> > > common.php
> > > > as we want to.
> > >
> > > If you select Local/Network location in Publishing properties and then
> > > specify your database name in the Databas properties, it is kept
> > separately
> > > from your FTP database settings. Basically, you can create 2 database
> > > profiles, one for your local server, and one for the ftp location.
> > >
> > >
> > >
> > > "Jeff Stuart" <jstuart-devel@neo.rr.com> wrote in message
> > >news:9c9rgs$1gg$1@mail.tankhill.com...
> > > > Ok... here's another suggestion:
> > > >
> > > > Currently, you store the connection parameters for a database in
> > > common.php.
> > > > Rather than doing that, move that OUT of common.php into another
file.
> > > This
> > > > way, we can upload the files to our production server, edit the new
> file
> > > > once to look at our production database, and still keep regenning
> > > common.php
> > > > as we want to.
> > > >
> > > > Or, I wonder... would this work with a custom connection stuff?
> Hmm...
> > > >
> > > > --
> > > > Jeff Stuart
> > > >jstuart@neo.rr.com
> > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>

CodeCharge
Posted: 04/27/2001, 10:58 AM

OK, this clarifies the issue somewhat.
Looks like your issue will occur only when you modify common.php, for
example by adding global module as you metnioned. Such cases are pretty rare
and I don't see as a justification to move the connection string out of the
common file. Unless there are other strong reasons that someone may point
to.

However, your specific case is already solved. If you use version 1.1.16 of
CodeCharge, you can specify your local database settings separately and
differently from your Ftp/server database settings. I described this in the
previous email/posting.

Adam


"Jeff Stuart" <jstuart-devel@neo.rr.com> wrote in message
news:9cc1v6$3ia$1@mail.tankhill.com...
> Yes BUT.. Let me explain my work flow and maybe it'll make more sense.
>
>
>
> I run codecharge here on my local workstation (where I'm typing this
> response).
>
> I have another machine right next to me running Linux, Mysql, Apache, and
> PHP which is my devel server. All of my codecharge generated files go
> there. Also, when I FIRST setup a new codecharge project, I point the DB
to
> my devel server.
>
> I have remote FTP server which is the actual production server. As I test
> things, I upload each of the files up to the production server so that
they
> can be used. In the process, I modify the common.php after I upload it so
> that it points to the PRODUCTION DB server which of course is NOT my devel
> server.
>
>
>
> Now, say I come back a day or so later and add a global module? Well, it
> rewrites common.php! Now IF it had a separate file that you included
(call
> it db_conn.inc) which ALL it had was this:
>
>
>
> define("DATABASE_NAME","");
>
> define("DATABASE_USER","");
>
> define("DATABASE_PASSWORD","");
>
> define("DATABASE_HOST","");
>
>
>
> Then I wouldn't lose my changes after I uploaded common.php up to the
> production server.
>
>
>
> NOW. FOR ME. I've worked around this. I've already got PHPLib installed
on
> the production server and therefore already have DB_Sql subclassed into my
> own DB setup. Therefore. ALL I do is just setup a custom connection and
my
> problem is solved. J
>
>
>
> I may be different than most other folks. Don't know. J
>
>
> --
> Jeff Stuart
>jstuart@neo.rr.com
>
> "CodeCharge" <support@codecharge.com> wrote in message
>news:9cb0qn$4pt$1@mail.tankhill.com...
> > OK Jeff. But you can modify common.php and keep it the way you want it,
> just
> > like you would the "other file".
> > I'm still not sure if anything would change by generating the db
settings
> to
> > another file. The another file would become equivalent to "common.php"
and
> > we'd be where we started :)
> >
> > Adam S.
> > CodeCharge Support
> >
> > "Jeff Stuart" <jstuart-devel@neo.rr.com> wrote in message
> >news:9cb046$3df$1@mail.tankhill.com...
> > > What I meant was that you have the following code in common.php:
> > >
> > > file://-- handling database connection
> > > include("./db_mysql.inc");
> > >
> > > define("DATABASE_NAME","");
> > > define("DATABASE_USER","");
> > > define("DATABASE_PASSWORD","");
> > > define("DATABASE_HOST","");
> > >
> > > file://-- Database class
> > > $db = new DB_Sql();
> > > $db->Database = DATABASE_NAME;
> > > $db->User = DATABASE_USER;
> > > $db->Password = DATABASE_PASSWORD;
> > > $db->Host = DATABASE_HOST;
> > >
> > > and since this is going into an existing PHPLib enabled server, I
> already
> > > have my db classes... SO.. what I was HOPING to be able to do was
change
> > the
> > > new DB_Sql to new DB_Wod (which is the name of my db).
> > >
> > > Turns out if I use the custom connections thingie, I get this:
> > >
> > > $db = new DB_Wod();
> > >
> > > which does EXACTLY what I want. :) So you guys have already
anticipated
> > my
> > > needs... :)
> > >
> > >
> > > --
> > > Jeff Stuart
> > >jstuart@neo.rr.com
> > >
> > > "CodeCharge" <support@codecharge.com> wrote in message
> > >news:9cav7g$1ub$1@mail.tankhill.com...
> > > > > Rather than doing that, move that OUT of common.php into another
> file.
> > > >
> > > > Common.php is already that another file.
> > > > There is no other purpose to Common.php but to store common settings
> and
> > > > functions.
> > > > If we generated the connection string to a different file, you'd
> arrive
> > at
> > > > the same situation.
> > > >
> > > > > This
> > > > > way, we can upload the files to our production server, edit the
new
> > file
> > > > > once to look at our production database, and still keep regenning
> > > > common.php
> > > > > as we want to.
> > > >
> > > > If you select Local/Network location in Publishing properties and
then
> > > > specify your database name in the Databas properties, it is kept
> > > separately
> > > > from your FTP database settings. Basically, you can create 2
database
> > > > profiles, one for your local server, and one for the ftp location.
> > > >
> > > >
> > > >
> > > > "Jeff Stuart" <jstuart-devel@neo.rr.com> wrote in message
> > > >news:9c9rgs$1gg$1@mail.tankhill.com...
> > > > > Ok... here's another suggestion:
> > > > >
> > > > > Currently, you store the connection parameters for a database in
> > > > common.php.
> > > > > Rather than doing that, move that OUT of common.php into another
> file.
> > > > This
> > > > > way, we can upload the files to our production server, edit the
new
> > file
> > > > > once to look at our production database, and still keep regenning
> > > > common.php
> > > > > as we want to.
> > > > >
> > > > > Or, I wonder... would this work with a custom connection stuff?
> > Hmm...
> > > > >
> > > > > --
> > > > > Jeff Stuart
> > > > >jstuart@neo.rr.com
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>


   


These are Community Forums for users to exchange information.
If you would like to obtain technical product help please visit http://support.yessoftware.com.

PHP Reports

Visually create Web Reports in PHP, ASP, .NET, Java, Perl and ColdFusion.
CodeCharge.com

Home   |    Search   |    Members   |    Register   |    Login


Powered by UltraApps Forum created with CodeCharge Studio
Copyright © 2003-2004 by UltraApps.com  and YesSoftware, Inc.