473,322 Members | 1,846 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,322 software developers and data experts.

Best way to integrate classes

Hi all.

I'm working here on a small project of mine. I'm not new to programming, but
I'm new to PHP. You have to understand that I'm coming from C++, OOP world,
so my code might seems a little too "object"-ified.

Anyways, I've created a wrapper class for MySQL connectivity. It's barebones
for now, no error checking or anything. So now I'm trying to create
user/session-handling class that would work with the data stored in the
database via DB class.

What is the best approach to integrate the two classes? How would you do it?

I see three possible solutions:
1.) Have the Session class extend the DB class?
class Session extends DB {
// login();
// logout();
// etc...
}

This doesn't really make sense to me in terms of logical iheritance. Session
is not really a DB-handling class. Besides, I'm unclear on a few things
here. Will the constructor for DB class be called automatically and create a
connection (it should in my mind) or should I be re-initializing all
inherited vars?
2.) First, instantiate an object of DB:
$oDB = new DB();

Then use it via global declaration in Session class

class Session {
global $oDB;

// login();
// logout();
// etc...
}

Not the prettiest way, but it works. It would also allow to reuse the same
MySQL connection via $oDB object further in the code.
3.) Instantiate DB object as part of Session's vars:

class Session {
$_oDB = new DB();

// login();
// logout();
// etc...
}

The only drawback I can see is that I would be unable to reuse the MySQL
connection outside of Session class. I'd have to create a totaly new DB
object.

Oh and here's the DB class.

// +++++++++++++++++++ DB CLASS +++++++++++++++++
class DB {

// public variables
var $sServer;
var $sPort;
var $sUser;
var $sPass;
var $sDatabase;

// private variables
var $_link_id;
var $_result_id;
var $_last_query;

// Constructor, uses db_connect()
function DB ($user, $pass, $database, $server='localhost', $port='3306') {
$this->connect($user, $pass, $database, $server, $port);
}

// Opens a connection to a db-server and selects a db
function connect ($user, $pass, $database, $servet, $port) {
$this->sServer = $server;
$this->sPort = $port;
$this->sUser = $user;
$this->sPass = $pass;
$this->sDatabase = $database;

$this->_link_id = mysql_connect("$server:$port", $user, $pass);

$this->select_db($database, $this->_link_id);
}

// Closes connection to the database
function disconnect () {
$this->free_result();
mysql_close($this->_link_id);
unset ($this->_link_id, $this->_result_id);
}

// Changes database in use
function select_db ($database) {
mysql_select_db($this->sDatabase, $this->_link_id);
}

// Run db query
function query ($query) {
$this->_last_query = $query;
$this->_result_id = mysql_query($query, $this->_link_id);
}

// Frees up the memory required to store last query's results
function free_result () {
mysql_free_result($this->_result_id);
unset ($this->_result_id);
}

// Returns a single record array from the query results
function fetch_row () {
return mysql_fetch_row($this->_result_id);
}

// Returns a single record as associative array from query results
function fetch_assoc () {
return mysql_fetch_assoc($this->_result_id);
}

// Returns a single record as object from query results
function fetch_object () {
return mysql_fetch_object($this->_result_id);
}

// Returns number of records found after SELECT statement
function num_rows () {
return mysql_num_rows($this->_result_id);
}

// Return number of rows affected from INSERT, UPDATE, DELETE statements
function affected_rows () {
return mysql_affected_rows($this->_link_id);
}

// Returns current db link_id
function get_link_id () {
return $this->_link_id;
}

// Return current db result_id
function get_result_id () {
return $this->_result_id;
}

// Return last query ran
function get_last_query () {
return $this->_last_query;
}
// -----------------------------------------------------------------------
}

Any comments are welcome, perhaps there're other way to do this that I'm not
seeing.

--
Swartz
Jul 17 '05 #1
35 2585
On 2004-03-06, Swartz wrote:
Hi all.

I'm working here on a small project of mine. I'm not new to programming, but
I'm new to PHP. You have to understand that I'm coming from C++, OOP world,
so my code might seems a little too "object"-ified.

Anyways, I've created a wrapper class for MySQL connectivity. It's barebones
for now, no error checking or anything. So now I'm trying to create
user/session-handling class that would work with the data stored in the
database via DB class.

What is the best approach to integrate the two classes? How would you do it?

I see three possible solutions:
1.) Have the Session class extend the DB class?
class Session extends DB {
// login();
// logout();
// etc...
}

This doesn't really make sense to me in terms of logical iheritance. Session
is not really a DB-handling class. Besides, I'm unclear on a few things
here. Will the constructor for DB class be called automatically and create a
connection (it should in my mind) or should I be re-initializing all
inherited vars?
2.) First, instantiate an object of DB:
$oDB = new DB();

Then use it via global declaration in Session class

class Session {
global $oDB;

// login();
// logout();
// etc...
}

Not the prettiest way, but it works. It would also allow to reuse the same
MySQL connection via $oDB object further in the code.
3.) Instantiate DB object as part of Session's vars:

class Session {
$_oDB = new DB();

// login();
// logout();
// etc...
}

The only drawback I can see is that I would be unable to reuse the MySQL
connection outside of Session class. I'd have to create a totaly new DB
object.

I'd go route 3. You can still access the session's DB object:

$my_session = new Session ();

$sql = 'SELECT blah FROM blah';

$my_session -> _oDB -> db_query ( $sql);

HTH
--
Mike Peters
mike [-AT-] ice2o [-DOT-] com
http://www.ice2o.com
Jul 17 '05 #2
jn
"Mike Peters" <o0****************@THIShotmail.com> wrote in message
news:88******************************@news.teranew s.com...
On 2004-03-06, Swartz wrote:
Hi all.

I'm working here on a small project of mine. I'm not new to programming, but I'm new to PHP. You have to understand that I'm coming from C++, OOP world, so my code might seems a little too "object"-ified.

Anyways, I've created a wrapper class for MySQL connectivity. It's barebones for now, no error checking or anything. So now I'm trying to create
user/session-handling class that would work with the data stored in the
database via DB class.

What is the best approach to integrate the two classes? How would you do it?
I see three possible solutions:
1.) Have the Session class extend the DB class?
class Session extends DB {
// login();
// logout();
// etc...
}

This doesn't really make sense to me in terms of logical iheritance. Session is not really a DB-handling class. Besides, I'm unclear on a few things
here. Will the constructor for DB class be called automatically and create a connection (it should in my mind) or should I be re-initializing all
inherited vars?
2.) First, instantiate an object of DB:
$oDB = new DB();

Then use it via global declaration in Session class

class Session {
global $oDB;

// login();
// logout();
// etc...
}

Not the prettiest way, but it works. It would also allow to reuse the same MySQL connection via $oDB object further in the code.
3.) Instantiate DB object as part of Session's vars:

class Session {
$_oDB = new DB();

// login();
// logout();
// etc...
}

The only drawback I can see is that I would be unable to reuse the MySQL
connection outside of Session class. I'd have to create a totaly new DB
object.

I'd go route 3. You can still access the session's DB object:

$my_session = new Session ();

$sql = 'SELECT blah FROM blah';

$my_session -> _oDB -> db_query ( $sql);

HTH
--
Mike Peters
mike [-AT-] ice2o [-DOT-] com
http://www.ice2o.com


That's not a good practice though is it? Wasn't that object supposed to be
private to the session class?

By the way, I'm no expert on OOP :)
Jul 17 '05 #3
On 2004-03-06, jn wrote:
"Mike Peters" <o0****************@THIShotmail.com> wrote in message
news:88******************************@news.teranew s.com...
On 2004-03-06, Swartz wrote:
> Hi all.
>
> I'm working here on a small project of mine. I'm not new to programming, but > I'm new to PHP. You have to understand that I'm coming from C++, OOP world, > so my code might seems a little too "object"-ified.
>
> Anyways, I've created a wrapper class for MySQL connectivity. It's barebones > for now, no error checking or anything. So now I'm trying to create
> user/session-handling class that would work with the data stored in the
> database via DB class.
>
> What is the best approach to integrate the two classes? How would you do it? >
> I see three possible solutions:
>
>
> 1.) Have the Session class extend the DB class?
> class Session extends DB {
> // login();
> // logout();
> // etc...
> }
>
> This doesn't really make sense to me in terms of logical iheritance. Session > is not really a DB-handling class. Besides, I'm unclear on a few things
> here. Will the constructor for DB class be called automatically and create a > connection (it should in my mind) or should I be re-initializing all
> inherited vars?
>
>
> 2.) First, instantiate an object of DB:
> $oDB = new DB();
>
> Then use it via global declaration in Session class
>
> class Session {
> global $oDB;
>
> // login();
> // logout();
> // etc...
> }
>
> Not the prettiest way, but it works. It would also allow to reuse the same > MySQL connection via $oDB object further in the code.
>
>
> 3.) Instantiate DB object as part of Session's vars:
>
> class Session {
> $_oDB = new DB();
>
> // login();
> // logout();
> // etc...
> }
>
> The only drawback I can see is that I would be unable to reuse the MySQL
> connection outside of Session class. I'd have to create a totaly new DB
> object.
>

I'd go route 3. You can still access the session's DB object:

$my_session = new Session ();

$sql = 'SELECT blah FROM blah';

$my_session -> _oDB -> db_query ( $sql);

HTH
--
Mike Peters
mike [-AT-] ice2o [-DOT-] com
http://www.ice2o.com


That's not a good practice though is it? Wasn't that object supposed to be
private to the session class?

By the way, I'm no expert on OOP :)

PHP4 has no concept of public / private, maybe the OP is using PHP5 but he
didn't say so. Anyway this is merely an example of containment - the
Session object 'has a' database object. We can access it directly like
above (as if we'd declared it public) or we could write a 'public' method
for our session class to access the 'private' object, the end result is the
same. I can see your point, and, in a compiled language I would agree, but
we're using php here so we also need to think about performance and the extra
overhead it would take to do it the 'right' way, at least in PHP4 where
the object model is less than perfect.
--
Mike Peters
mike [-AT-] ice2o [-DOT-] com
http://www.ice2o.com
Jul 17 '05 #4
Hi.
3.) Instantiate DB object as part of Session's vars:

class Session {
$_oDB = new DB();

// login();
// logout();
// etc...
}

I guess I better correct myself before somebody else does.
Unfortunatelly u cant have dynamic created values assigned to a class
variable.
Expression $_oDB = new DB() is invalid.

So the code should be the following:

class Session {
var $_oDB;

function Session () {
$this->_oDB = new DB();
}
// login, logout, etc

}
I'd go route 3. You can still access the session's DB object:
$my_session = new Session ();
$sql = 'SELECT blah FROM blah';
$my_session -> _oDB -> db_query ( $sql);

That's not a good practice though is it? Wasn't that object supposed to be
private to the session class?

Well, technically yes, it is not a good OOP. Mainly because class vars that
start with an underscore "_" are private vars by convention that many PHP
programmers use.

--
Swartz

Jul 17 '05 #5
On 2004-03-07, Swartz wrote:
Hi.
> > 3.) Instantiate DB object as part of Session's vars:
> >
> > class Session {
> > $_oDB = new DB();
> >
> > // login();
> > // logout();
> > // etc...
> > }
I guess I better correct myself before somebody else does.
Unfortunatelly u cant have dynamic created values assigned to a class
variable.
Expression $_oDB = new DB() is invalid.

So the code should be the following:

class Session {
var $_oDB;

function Session () {
$this->_oDB = new DB();
}
// login, logout, etc

}
I'd assumed your original post was merely shorthand and you'd meant this
anyway.
> I'd go route 3. You can still access the session's DB object:
> $my_session = new Session ();
> $sql = 'SELECT blah FROM blah';
> $my_session -> _oDB -> db_query ( $sql);

That's not a good practice though is it? Wasn't that object supposed to be
private to the session class?

Well, technically yes, it is not a good OOP. Mainly because class vars that
start with an underscore "_" are private vars by convention that many PHP
programmers use.

--
Swartz

--
Mike Peters
mike [-AT-] ice2o [-DOT-] com
http://www.ice2o.com
Jul 17 '05 #6
"Swartz" <sw****@inbox.ru> wrote in message
news:<10*************@corp.supernews.com>...

I'm working here on a small project of mine. I'm not new to programming, but
I'm new to PHP. You have to understand that I'm coming from C++, OOP world,
so my code might seems a little too "object"-ified.
Actually, it doesn't seem "a little too objectified"; it seems
unnecessarily objectified. You are creating lots of overhead
here...
What is the best approach to integrate the two classes?
The best approach is not to have classes at all, unless you
need them.
How would you do it?
By writing standalone functions: login(), logout(), etc. Ask
yourself a simple question: will you ever have more than one
instance of your Session class running? Most likely, the answer
to that question is no, so you will do just fine with standalone
functions; they will get the job done and won't create any
unnecessary overhead...
perhaps there're other way to do this that I'm not seeing.


Of course. Try to unlearn OOP, if you can.

Cheers,
NC
Jul 17 '05 #7
Worst advice ever... im sorry.

I create classes for everything. Why? Because I might write a project in a
few months, instead of starting from scratch I can just include those
classes.
Of course. Try to unlearn OOP, if you can.
Clearly you have never done much OOP.

Wait for php 5 and things are going to change.
"Nikolai Chuvakhin" <nc@iname.com> wrote in message
news:32**************************@posting.google.c om... "Swartz" <sw****@inbox.ru> wrote in message
news:<10*************@corp.supernews.com>...

I'm working here on a small project of mine. I'm not new to programming, but I'm new to PHP. You have to understand that I'm coming from C++, OOP world, so my code might seems a little too "object"-ified.


Actually, it doesn't seem "a little too objectified"; it seems
unnecessarily objectified. You are creating lots of overhead
here...
What is the best approach to integrate the two classes?


The best approach is not to have classes at all, unless you
need them.
How would you do it?


By writing standalone functions: login(), logout(), etc. Ask
yourself a simple question: will you ever have more than one
instance of your Session class running? Most likely, the answer
to that question is no, so you will do just fine with standalone
functions; they will get the job done and won't create any
unnecessary overhead...
perhaps there're other way to do this that I'm not seeing.


Of course. Try to unlearn OOP, if you can.

Cheers,
NC

Jul 17 '05 #8
Swartz wrote:
Hi all.

I'm working here on a small project of mine. I'm not new to programming, but
I'm new to PHP. You have to understand that I'm coming from C++, OOP world,
so my code might seems a little too "object"-ified.

Anyways, I've created a wrapper class for MySQL connectivity. It's barebones
for now, no error checking or anything. So now I'm trying to create
user/session-handling class that would work with the data stored in the
database via DB class.

What is the best approach to integrate the two classes? How would you do it?

I see three possible solutions:
1.) Have the Session class extend the DB class? (snip inheritence)
2.) First, instantiate an object of DB:
$oDB = new DB();

Then use it via global declaration in Session class (snip use of a global)
3.) Instantiate DB object as part of Session's vars:

class Session {
$_oDB = new DB();

// login();
// logout();
// etc...
}

The only drawback I can see is that I would be unable to reuse the MySQL
connection outside of Session class. I'd have to create a totaly new DB
object.


And what about :

class Session
{
var $_dbObject;

function Session(&$dbObject)
{
$this->dbObject =& $dbObject;
}
/* ... */
}

$db = new DB();
$session = new Session($db);

Easy enough, no ? I'd thought that <quote>coming from C++, OOP
world</quote>, you would at least know such a basic OO construction ?-)

Bruno

Jul 17 '05 #9
Nikolai Chuvakhin wrote:
"Swartz" <sw****@inbox.ru> wrote in message
news:<10*************@corp.supernews.com>...
I'm working here on a small project of mine. I'm not new to programming, but
I'm new to PHP. You have to understand that I'm coming from C++, OOP world,
so my code might seems a little too "object"-ified.


Actually, it doesn't seem "a little too objectified"; it seems
unnecessarily objectified. You are creating lots of overhead
here...
What is the best approach to integrate the two classes?


The best approach is not to have classes at all, unless you
need them.
How would you do it?


By writing standalone functions: login(), logout(), etc. Ask
yourself a simple question: will you ever have more than one
instance of your Session class running? Most likely, the answer
to that question is no, so you will do just fine with standalone
functions; they will get the job done and won't create any
unnecessary overhead...


All your rant against OO could be justified if PHP had any other support
for modularity. Since this is not the case, and there's no way to have
functions or vars existing on a 'module' scope only, the only way to
write clean PHP code is to use OO.

The "unnecessary overhead" is the price to pay to have clean, modular
code with lo coupling, and as such is *never* "unnecessary" except
perhaps for the most basic, throw-away scripts.
Bruno

Jul 17 '05 #10
On 2004-03-06, Swartz <sw****@inbox.ru> wrote:
Hi all.

I'm working here on a small project of mine. I'm not new to programming, but
I'm new to PHP. You have to understand that I'm coming from C++, OOP world,
so my code might seems a little too "object"-ified.

Anyways, I've created a wrapper class for MySQL connectivity. It's barebones
for now, no error checking or anything. So now I'm trying to create
user/session-handling class that would work with the data stored in the
database via DB class.

I see three possible solutions:
1.) Have the Session class extend the DB class?
2.) First, instantiate an object of DB:
Then use it via global declaration in Session class
3.) Instantiate DB object as part of Session's vars:


I'd go for the 4th solution: An interface Session with functions login,
logout, etc...

Then implement this interface in a class DBSession and pass a reference
to the DB object as an argument in the constructor.

--
http://home.mysth.be/~timvw
Jul 17 '05 #11

"Bruno Desthuilliers" <bd*****************@free.quelquepart.fr> wrote in
message news:40*********************@news.free.fr...
Nikolai Chuvakhin wrote:
"Swartz" <sw****@inbox.ru> wrote in message
news:<10*************@corp.supernews.com>...
I'm working here on a small project of mine. I'm not new to programming, butI'm new to PHP. You have to understand that I'm coming from C++, OOP world,so my code might seems a little too "object"-ified.


Actually, it doesn't seem "a little too objectified"; it seems
unnecessarily objectified. You are creating lots of overhead
here...
What is the best approach to integrate the two classes?


The best approach is not to have classes at all, unless you
need them.
How would you do it?


By writing standalone functions: login(), logout(), etc. Ask
yourself a simple question: will you ever have more than one
instance of your Session class running? Most likely, the answer
to that question is no, so you will do just fine with standalone
functions; they will get the job done and won't create any
unnecessary overhead...


All your rant against OO could be justified if PHP had any other support
for modularity. Since this is not the case, and there's no way to have
functions or vars existing on a 'module' scope only, the only way to
write clean PHP code is to use OO.


What is your definition of 'clean' code. It is possible to write beautiful
code without using OO, just as it is possible to write crap code with OO.
Using one technique or the other does not guarantee that your code will be
either excellent or excrement - it is not the technique, it is the
technician.

--
Tony Marston

http://www.tonymarston.net

Jul 17 '05 #12
[Top-post fixed.]

"Hayden Kirk" <sp**@spam.com> wrote in message news:<eN********************@news02.tsnz.net>...
"Nikolai Chuvakhin" <nc@iname.com> wrote in message
news:32**************************@posting.google.c om...
"Swartz" <sw****@inbox.ru> wrote in message
news:<10*************@corp.supernews.com>...

I'm working here on a small project of mine. I'm not new to programming, but I'm new to PHP. You have to understand that I'm coming from C++, OOP world, so my code might seems a little too "object"-ified.


Actually, it doesn't seem "a little too objectified"; it seems
unnecessarily objectified. You are creating lots of overhead
here...
What is the best approach to integrate the two classes?


The best approach is not to have classes at all, unless you
need them.
How would you do it?


By writing standalone functions: login(), logout(), etc. Ask
yourself a simple question: will you ever have more than one
instance of your Session class running? Most likely, the answer
to that question is no, so you will do just fine with standalone
functions; they will get the job done and won't create any
unnecessary overhead...
perhaps there're other way to do this that I'm not seeing.

Worst advice ever... im sorry.

I create classes for everything. Why? Because I might write a project in a
few months, instead of starting from scratch I can just include those
classes.


I also use classes not for this reason; but as I like OOP. Nikolai
Chuvakhin may reuse his functions instead of classes.
Of course. Try to unlearn OOP, if you can.


Clearly you have never done much OOP.


Sounds like a newcomer? Nikolai Chuvakhin is one among many
anti-OOP regulars here :-)

--
"I don't believe in the God who doesn't give me food, but shows me
heaven!"--Swami Vivekanandha
Email: rrjanbiah-at-Y!com
Jul 17 '05 #13
"Swartz" <sw****@inbox.ru> wrote in message news:<10*************@corp.supernews.com>...
What is the best approach to integrate the two classes? How would you do it?
I see three possible solutions:
Indeed a nice question.
1.) Have the Session class extend the DB class?
Unfortunately this style is bit common in PHP. IIRC, this is bit
common among people who use PEAR. I don't know, why people inherit the
classes that are not actually a super class. I often see this: PHP
programmers often extends a class as a "fix" to "add" some more
methods instead of viewing it as a super object.
2.) First, instantiate an object of DB:
$oDB = new DB();
Then use it via global declaration in Session class
class Session {
global $oDB;
I'm alergic to global variables and using them inside the classes.
For me, an object should not be controlled by a public variable.
3.) Instantiate DB object as part of Session's vars:
class Session {
$_oDB = new DB();


This is bit awkward.

I usually go for Bruno Desthuilliers's solution.

--
"I don't believe in the God who doesn't give me food, but shows me
heaven!"--Swami Vivekanandha
Email: rrjanbiah-at-Y!com
Jul 17 '05 #14
"Swartz" <sw****@inbox.ru> wrote in message news:<10*************@corp.supernews.com>...
What is the best approach to integrate the two classes? How would you do it?
I see three possible solutions:
Indeed a nice question.
1.) Have the Session class extend the DB class?
Unfortunately this style is bit common in PHP. IIRC, this is bit
common among people who use PEAR. I don't know, why people inherit the
classes that are not actually a super class. I often see this: PHP
programmers often extends a class as a "fix" to "add" some more
methods instead of viewing it as a super object.

2.) First, instantiate an object of DB:
$oDB = new DB();
Then use it via global declaration in Session class
class Session {
global $oDB;
I'm alergic to global variables and using them inside the classes.
For me, an object should not be controlled by a public variable.
3.) Instantiate DB object as part of Session's vars:
class Session {
$_oDB = new DB();


This is bit awkward.

I usually go for Bruno Desthuilliers's solution.

--
"I don't believe in the God who doesn't give me food, but shows me
heaven!"--Swami Vivekanandha
Email: rrjanbiah-at-Y!com
Jul 17 '05 #15
"Swartz" <sw****@inbox.ru> wrote in message news:<10*************@corp.supernews.com>...
What is the best approach to integrate the two classes? How would you do it?
I see three possible solutions:
Indeed a nice question.
1.) Have the Session class extend the DB class?
Unfortunately this style is bit common in PHP. IIRC, this is bit
common among people who use PEAR. I don't know, why people inherit the
classes that are not actually a super class. I often see this: PHP
programmers often extends a class as a "fix" to "add" some more
methods instead of viewing it as a super object.

2.) First, instantiate an object of DB:
$oDB = new DB();
Then use it via global declaration in Session class
class Session {
global $oDB;
I'm alergic to global variables and using them inside the classes.
For me, an object should not be controlled by a public variable.
3.) Instantiate DB object as part of Session's vars:
class Session {
$_oDB = new DB();


This is bit awkward.

I usually go for Bruno Desthuilliers's solution.

--
"I don't believe in the God who doesn't give me food, but shows me
heaven!"--Swami Vivekanandha
Email: rrjanbiah-at-Y!com
Jul 17 '05 #16
ng**********@rediffmail.com (R. Rajesh Jeba Anbiah) wrote in message news:<ab*************************@posting.google.c om>...
"Swartz" <sw****@inbox.ru> wrote in message news:<10*************@corp.supernews.com>...


<snip>

Apologies for the multiple post. I didn't expect it. Sorry.
Jul 17 '05 #17
Tony Marston wrote:
"Bruno Desthuilliers" <bd*****************@free.quelquepart.fr> wrote in
message news:40*********************@news.free.fr... (snip)
All your rant against OO could be justified if PHP had any other support
for modularity. Since this is not the case, and there's no way to have
functions or vars existing on a 'module' scope only, the only way to
write clean PHP code is to use OO.

What is your definition of 'clean' code. It is possible to write beautiful
code without using OO,


I do absolutely agree, as soon as the language offers a good support for
modularity - which is not the case with PHP, where everything is either
global, local to a function or member of an object. Which means that the
only way to have 'module-scope' identifiers is to use classes, either as
modules or in a more OO way.
just as it is possible to write crap code with OO.
I do absolutely agree too, and never said otherwise.
Using one technique or the other does not guarantee that your code will be
either excellent or excrement - it is not the technique, it is the
technician.


<AOL>.
Bruno

Jul 17 '05 #18
R. Rajesh Jeba Anbiah wrote:
"Swartz" <sw****@inbox.ru> wrote in message news:<10*************@corp.supernews.com>...
What is the best approach to integrate the two classes? How would you do it?
I see three possible solutions:

Indeed a nice question.

1.) Have the Session class extend the DB class?

Unfortunately this style is bit common in PHP. IIRC, this is bit
common among people who use PEAR. I don't know, why people inherit the
classes that are not actually a super class. I often see this: PHP
programmers often extends a class as a "fix" to "add" some more
methods instead of viewing it as a super object.


Well, it surprised me too at first too, but then, PHP being dynamically
typed, polymorphism doesn't depends on inheritence relationship, so you
just have it as an easy code reuse facility, a bit like using mix-ins.

Now I would not advise anyone to abuse of this kind of coding technique,
since it is far less cleanly decoupled as the aggregation/delegation
approach, and I'm not sure it buys that much when it comes to
performances...

my 2 cents,
Bruno

Jul 17 '05 #19
Hi!
I'd go for the 4th solution: An interface Session with functions login,
logout, etc...
Then implement this interface in a class DBSession and pass a reference
to the DB object as an argument in the constructor.


Hey, I like your idea of interfaces! Can you guess why? :)
Thanks for your input!

--
Swartz
Jul 17 '05 #20

"Bruno Desthuilliers" <bd*****************@free.quelquepart.fr> wrote in
message news:40*********************@news.free.fr...
Swartz wrote:
Hi all.

I'm working here on a small project of mine. I'm not new to programming, but I'm new to PHP. You have to understand that I'm coming from C++, OOP world, so my code might seems a little too "object"-ified.

Anyways, I've created a wrapper class for MySQL connectivity. It's barebones for now, no error checking or anything. So now I'm trying to create
user/session-handling class that would work with the data stored in the
database via DB class.

What is the best approach to integrate the two classes? How would you do it?
I see three possible solutions:
1.) Have the Session class extend the DB class?

(snip inheritence)

2.) First, instantiate an object of DB:
$oDB = new DB();

Then use it via global declaration in Session class

(snip use of a global)

3.) Instantiate DB object as part of Session's vars:
>
class Session {
$_oDB = new DB();

// login();
// logout();
// etc...
}

The only drawback I can see is that I would be unable to reuse the MySQL
connection outside of Session class. I'd have to create a totaly new DB
object.


And what about :

class Session
{
var $_dbObject;

function Session(&$dbObject)
{
$this->dbObject =& $dbObject;
}
/* ... */
}

$db = new DB();
$session = new Session($db);

Easy enough, no ? I'd thought that <quote>coming from C++, OOP
world</quote>, you would at least know such a basic OO construction ?-)

I sense a lot of irony in your post ;) Yes, it looks very familiar to me.

PS. IMO your proposal is the same as my method #2 (using global
declaration). Correct me if I'm wrong but isn't declaring a var as global in
a function/class scope in PHP is exactly the same as passing the var as
reference? Different declaration/instantiation syntax, but further use is
identical.

--
Swartz


Jul 17 '05 #21
Swartz wrote:
"Bruno Desthuilliers" <bd*****************@free.quelquepart.fr> wrote in
message news:40*********************@news.free.fr...
(snip)

And what about :

class Session
{
var $_dbObject;

function Session(&$dbObject)
{
$this->dbObject =& $dbObject;
}
/* ... */
}

$db = new DB();
$session = new Session($db);

Easy enough, no ? I'd thought that <quote>coming from C++, OOP
world</quote>, you would at least know such a basic OO construction ?-)


I sense a lot of irony in your post ;)

Err... well... how to say ?-)
Yes, it looks very familiar to me. PS. IMO your proposal is the same as my method #2 (using global
declaration). Correct me
Well, if you ask for it....
if I'm wrong but isn't declaring a var as global in
a function/class scope in PHP is exactly the same as passing the var as
reference?
Not at all. Where did you get the idea that globals and refs would be
different in PHP from what they are in any other language ? A global is
a global. period. And a reference is, well, a reference.
Different declaration/instantiation syntax, but further use is
identical.


Nop. With a global, your objects will depend on the existence of a
global variable. You will have to carry this <beep> global in all your
code, whether it makes sens to have global or not. That's how you ends
up with 150+ globals in your project, some of them being just duplicated
objects because class A needed the global DB object to be named $foo
while class B wanted it to be named $bar.

With aggregation[/delegation], you clearly document dependencies, you
don't add any unnecessary and undocumented (or poorly documented)
dependencies, you don't pollute the global namespace, and you have
maximum flexibility. In your case, if the DB object is used *only* by
the Session object, you just instanciate the DB object when you
instanciate the Session object :

$session =& new Session(new DB(args...), ...);

Or you can have different DB objects shared by different groups of other
objects, etc...

I once had to clean up, refactor and try to add some modularity to a
program (around 60 kloc, all procedural code) using about a hundred
globals (yuck). The language used on this project shared some, err,
'features' of PHP, like not having any other support for modularity than
OOP. You can believe me : you definitively *dont* want any global in
your classes, since it makes the whole point of OO moot.

The only exceptions I'd make when it comes to PHP are predefined globals
like $_REQUEST and $_SERVER, and even then I'd be really carefull to use
those special vars only where it really makes sens and happens to be the
cleanest solution.

My 2 cents
Bruno

Jul 17 '05 #22
Bruno Desthuilliers <bd*****************@free.quelquepart.fr> wrote in message news:<40*********************@news.free.fr>...
Swartz wrote:
Hi all.

I'm working here on a small project of mine. I'm not new to programming, but
I'm new to PHP. You have to understand that I'm coming from C++, OOP world,
so my code might seems a little too "object"-ified.

Anyways, I've created a wrapper class for MySQL connectivity. It's barebones
for now, no error checking or anything. So now I'm trying to create
user/session-handling class that would work with the data stored in the
database via DB class.

What is the best approach to integrate the two classes? How would you do it?

I see three possible solutions:
1.) Have the Session class extend the DB class?

(snip inheritence)

2.) First, instantiate an object of DB:
$oDB = new DB();

Then use it via global declaration in Session class

(snip use of a global)

3.) Instantiate DB object as part of Session's vars:
>
class Session {
$_oDB = new DB();

// login();
// logout();
// etc...
}

The only drawback I can see is that I would be unable to reuse the MySQL
connection outside of Session class. I'd have to create a totaly new DB
object.


And what about :

class Session
{
var $_dbObject;

function Session(&$dbObject)
{
$this->dbObject =& $dbObject;
}
/* ... */
}

$db = new DB();
$session = new Session($db);

Easy enough, no ? I'd thought that <quote>coming from C++, OOP
world</quote>, you would at least know such a basic OO construction ?-)

Bruno


To pass by reference the DB object is the best solution in PHP4. I
don´t know if I am right but with PHP5 all is passed by reference.

Mark D.B.D
Jul 17 '05 #23
On 2004-03-09, Swartz <sw****@inbox.ru> wrote:
Hi!
I'd go for the 4th solution: An interface Session with functions login,
logout, etc...
Then implement this interface in a class DBSession and pass a reference
to the DB object as an argument in the constructor.


Hey, I like your idea of interfaces! Can you guess why? :)
Thanks for your input!


Forgot to mention you should lookup if your php version allows static
variables in a class (for the DB object).

--
http://home.mysth.be/~timvw
Jul 17 '05 #24
Tim Van Wassenhove wrote:
On 2004-03-09, Swartz <sw****@inbox.ru> wrote:
Hi!

I'd go for the 4th solution: An interface Session with functions login,
logout, etc...
Then implement this interface in a class DBSession and pass a reference
to the DB object as an argument in the constructor.


Hey, I like your idea of interfaces! Can you guess why? :)
Thanks for your input!

Forgot to mention you should lookup if your php version allows static
variables in a class (for the DB object).

You surely know that PHP4 does not allow this.

Jul 17 '05 #25
Tim Van Wassenhove wrote:
On 2004-03-06, Swartz <sw****@inbox.ru> wrote:
Hi all.

I'm working here on a small project of mine. I'm not new to programming, but
I'm new to PHP. You have to understand that I'm coming from C++, OOP world,
so my code might seems a little too "object"-ified.

Anyways, I've created a wrapper class for MySQL connectivity. It's barebones
for now, no error checking or anything. So now I'm trying to create
user/session-handling class that would work with the data stored in the
database via DB class.

I see three possible solutions:
1.) Have the Session class extend the DB class?
2.) First, instantiate an object of DB:
Then use it via global declaration in Session class
3.) Instantiate DB object as part of Session's vars:

I'd go for the 4th solution: An interface Session with functions login,
logout, etc...

Then implement this interface in a class DBSession and pass a reference
to the DB object as an argument in the constructor.


I must be a bit dumb, but I don't see *any* difference with my previous
proposition.

In a dynamically typed OO language, we have 'duck-like' polymorphism
(ie: 'if it behaves like a duck then it is a duck'), so just by writing
client code passing a given set of messages to an object and by writing
a class responding to the same set of messages, you actually and de
facto define an interface. So the simple fact of having a Session class
and client code for it is enough to define the Session interface.

So we're left with : having a class responding to the set of messages
that the client of a session would send, and having this class take a DB
object as an arg to the ctor. Which is exactly what I proposed - except
for the use of the word 'interface' !-)

Or did I miss something ?

Bruno
Jul 17 '05 #26
On 2004-03-10, Bruno Desthuilliers <bd*****************@free.quelquepart.fr> wrote:
Tim Van Wassenhove wrote:
On 2004-03-06, Swartz <sw****@inbox.ru> wrote:
Hi all.

I'm working here on a small project of mine. I'm not new to programming, but
I'm new to PHP. You have to understand that I'm coming from C++, OOP world,
so my code might seems a little too "object"-ified.

Anyways, I've created a wrapper class for MySQL connectivity. It's barebones
for now, no error checking or anything. So now I'm trying to create
user/session-handling class that would work with the data stored in the
database via DB class.

I see three possible solutions:
1.) Have the Session class extend the DB class?
2.) First, instantiate an object of DB:
Then use it via global declaration in Session class
3.) Instantiate DB object as part of Session's vars:

I'd go for the 4th solution: An interface Session with functions login,
logout, etc...

Then implement this interface in a class DBSession and pass a reference
to the DB object as an argument in the constructor.


I must be a bit dumb, but I don't see *any* difference with my previous
proposition.

In a dynamically typed OO language, we have 'duck-like' polymorphism
(ie: 'if it behaves like a duck then it is a duck'), so just by writing
client code passing a given set of messages to an object and by writing
a class responding to the same set of messages, you actually and de
facto define an interface. So the simple fact of having a Session class
and client code for it is enough to define the Session interface.

So we're left with : having a class responding to the set of messages
that the client of a session would send, and having this class take a DB
object as an arg to the ctor. Which is exactly what I proposed - except
for the use of the word 'interface' !-)

Or did I miss something ?


At the time i was writing this reply, your post had not arrived on my
newsserver...

Anyway here is an (imho) essential difference:
- Every session has a DBobject (composition) in your implementation

But it all comes down to the OP's requirements and how much layers of
abstraction he is willing to use...

--
http://home.mysth.be/~timvw
Jul 17 '05 #27
Tim Van Wassenhove wrote:
On 2004-03-10, Bruno Desthuilliers <bd*****************@free.quelquepart.fr> wrote:
(snip)

Or did I miss something ?


oops, sorry...
At the time i was writing this reply, your post had not arrived on my
newsserver...

Anyway here is an (imho) essential difference:
- Every session has a DBobject (composition) in your implementation
Err... Not quite, no. The DB object is passed by ref to the Session
object. But let's not waste time about this.
But it all comes down to the OP's requirements and how much layers of
abstraction he is willing to use...


Well, with dynamic typing, you save yourself the pain of having to write
boilerplate code just to make things abstract enough for the type system
to stop whining... But it all comes down to how much layer of
abstraction you are willing to write and maintain !-)

--
Bruno
" Any problem can be cured by an extra level of indirection -
except for 'too much levels of indirection' ".
--

Jul 17 '05 #28
On 2004-03-10, Bruno Desthuilliers <bd*****************@free.quelquepart.fr> wrote:
Tim Van Wassenhove wrote:
On 2004-03-10, Bruno Desthuilliers <bd*****************@free.quelquepart.fr> wrote:

(snip)

Or did I miss something ?


oops, sorry...
At the time i was writing this reply, your post had not arrived on my
newsserver...

Anyway here is an (imho) essential difference:
- Every session has a DBobject (composition) in your implementation


Err... Not quite, no. The DB object is passed by ref to the Session
object. But let's not waste time about this.

Err.. It does. Your code was like

class Session {
private static $dbObject;
...
}

This way they all have the same $dbObject, but:
Every instance of Session does have a $dbObject.

'Nough time wasted now ;)

--
http://home.mysth.be/~timvw
Jul 17 '05 #29
Bruno Desthuilliers <bd*****************@free.quelquepart.fr>
wrote in message news:<40*********************@news.free.fr>...
Nikolai Chuvakhin wrote:
Ask yourself a simple question: will you ever have more than one
instance of your Session class running? Most likely, the answer
to that question is no, so you will do just fine with standalone
functions; they will get the job done and won't create any
unnecessary overhead...
All your rant against OO could be justified if PHP had any other
support for modularity.


Support for modularity doesn't necessarily come from langiage. It
is entirely possible to support modularity through naming conventions
(which is exactly how it is done in the PHP core; functions specific
to a particular extension are prefixed with the name of that extension).
Since this is not the case, and there's no way to have functions
or vars existing on a 'module' scope only,
So? There's no way to have mysql_*() functions in a 'module' scope
only, too...
the only way to write clean PHP code is to use OO.
I disagree. The only way to write clean code is to write clean code
(whether in PHP or any other language). Take a look at "Statistical
Algorithms" section in "Applied Statistics" journal, for example.
The purpose of each subroutine is explained in natural language, all
identifiers and their meanings listed, archive goes back to 1968.
Since most of it is in Fortran, no OOP there...
The "unnecessary overhead" is the price to pay to have clean, modular
code with lo coupling, and as such is *never* "unnecessary" except
perhaps for the most basic, throw-away scripts.


I hear you, but can you seriously justify a 150-300% overhead (this is
the kind of overhead PEAR DB and M'base have) by this logic? Do users
really care about how low your coupling is? They want fast applications,
and speed requires a conscious effort of overhead minimization.

Cheers,
NC
Jul 17 '05 #30
Tim Van Wassenhove wrote:
On 2004-03-10, Bruno Desthuilliers <bd*****************@free.quelquepart.fr> wrote:
Tim Van Wassenhove wrote:
On 2004-03-10, Bruno Desthuilliers <bd*****************@free.quelquepart.fr> wrote:

(snip)

Or did I miss something ?

oops, sorry...

At the time i was writing this reply, your post had not arrived on my
newsserver...

Anyway here is an (imho) essential difference:
- Every session has a DBobject (composition)


This just aggregation, not composition.
in your implementation

Err... Not quite, no. The DB object is passed by ref to the Session
object. But let's not waste time about this.
Err.. It does. Your code was like

class Session {
private static $dbObject;
...
}


Err, excuse me Sir, but it's PHP4 here, not Java. My php interpreter
complains about the "private" and "static" modifiers.
This way they all have the same $dbObject,
Not mandatory.
but:
Every instance of Session does have a $dbObject.
No. Every instance of Session has a *ref* to *something* that *may* be
an instance of the DB class.

Ok, it would be cleaner to 'define' (at least conceptually) an abstract
class (call it interface or protocol if you prefer) that states what
services the Session class needs from the DB object, and then rename the
'$dbobject' member variable to something more general.

But now those kind of design decision depends on a context we don't
know, so : 'Nough time wasted now ;)

Right !-)

Bruno

Jul 17 '05 #31
Tim Van Wassenhove <eu**@pi.be> wrote in message news:<c2*************@ID-188825.news.uni-berlin.de>...
On 2004-03-10, Bruno Desthuilliers <bd*****************@free.quelquepart.fr> wrote:
Tim Van Wassenhove wrote:
On 2004-03-10, Bruno Desthuilliers <bd*****************@free.quelquepart.fr> wrote:

(snip)

Or did I miss something ?


oops, sorry...
At the time i was writing this reply, your post had not arrived on my
newsserver...

Anyway here is an (imho) essential difference:
- Every session has a DBobject (composition) in your implementation


Err... Not quite, no. The DB object is passed by ref to the Session
object. But let's not waste time about this.

Err.. It does. Your code was like

class Session {
private static $dbObject;
...
}

This way they all have the same $dbObject, but:
Every instance of Session does have a $dbObject.


Unfortunately, I couldn't get what is your style (what style you're
suggesting). If you get time, could you please post a piece of your
code/style?

--
"Democracy: Where all citizens are politicians and all politicians
are citizens"
Email: rrjanbiah-at-Y!com
Jul 17 '05 #32
On 2004-03-13, R. Rajesh Jeba Anbiah <ng**********@rediffmail.com> wrote:
Tim Van Wassenhove <eu**@pi.be> wrote in message news:<c2*************@ID-188825.news.uni-berlin.de>...
On 2004-03-10, Bruno Desthuilliers <bd*****************@free.quelquepart.fr> wrote:
> Tim Van Wassenhove wrote:
>> On 2004-03-10, Bruno Desthuilliers <bd*****************@free.quelquepart.fr> wrote:
>>
> (snip)
>
>>>
>>>Or did I miss something ?
>>
>
> oops, sorry...
>
>> At the time i was writing this reply, your post had not arrived on my
>> newsserver...
>>
>> Anyway here is an (imho) essential difference:
>> - Every session has a DBobject (composition) in your implementation
>
> Err... Not quite, no. The DB object is passed by ref to the Session
> object. But let's not waste time about this.

Err.. It does. Your code was like

class Session {
private static $dbObject;
...
}

This way they all have the same $dbObject, but:
Every instance of Session does have a $dbObject.


Unfortunately, I couldn't get what is your style (what style you're
suggesting). If you get time, could you please post a piece of your
code/style?


In this thread i suggested that an interface Session seemed more appropriate.
And that only an implementation of that interface should have knowledge
of DBObject class... As there can be implementations that authenticate
against LDAP etc (And thus not need DBObjects...)

If you want to know if i'm pro/contra OO methodology, i'm affraid i
can't answer your question. I try to pick the right tool for the right
job. Reminds me of an article that i've read, and was titled: For those
with a hammer, everything looks like a nail.

--
http://home.mysth.be/~timvw
Jul 17 '05 #33
Tim Van Wassenhove <eu**@pi.be> wrote in message news:<c2*************@ID-188825.news.uni-berlin.de>...
On 2004-03-13, R. Rajesh Jeba Anbiah <ng**********@rediffmail.com> wrote:
Tim Van Wassenhove <eu**@pi.be> wrote in message news:<c2*************@ID-188825.news.uni-berlin.de>... <snip>
Unfortunately, I couldn't get what is your style (what style you're
suggesting). If you get time, could you please post a piece of your
code/style?


In this thread i suggested that an interface Session seemed more appropriate.
And that only an implementation of that interface should have knowledge
of DBObject class... As there can be implementations that authenticate
against LDAP etc (And thus not need DBObjects...)

If you want to know if i'm pro/contra OO methodology, i'm affraid i
can't answer your question. I try to pick the right tool for the right
job. Reminds me of an article that i've read, and was titled: For those
with a hammer, everything looks like a nail.


If I understand right, yours and Bruno's solution are the same.
But, you claim some differences. I couldn't understand what you're
implying. That's why I asked some codes which may help me to
understand bit better.

--
"Democracy: Where all citizens are politicians and all politicians
are citizens"
Email: rrjanbiah-at-Y!com
Jul 17 '05 #34
On 2004-03-15, R. Rajesh Jeba Anbiah <ng**********@rediffmail.com> wrote:
Tim Van Wassenhove <eu**@pi.be> wrote in message news:<c2*************@ID-188825.news.uni-berlin.de>...
On 2004-03-13, R. Rajesh Jeba Anbiah <ng**********@rediffmail.com> wrote:
> Tim Van Wassenhove <eu**@pi.be> wrote in message news:<c2*************@ID-188825.news.uni-berlin.de>... <snip>
> Unfortunately, I couldn't get what is your style (what style you're
> suggesting). If you get time, could you please post a piece of your
> code/style?


In this thread i suggested that an interface Session seemed more appropriate.
And that only an implementation of that interface should have knowledge
of DBObject class... As there can be implementations that authenticate
against LDAP etc (And thus not need DBObjects...)

If you want to know if i'm pro/contra OO methodology, i'm affraid i
can't answer your question. I try to pick the right tool for the right
job. Reminds me of an article that i've read, and was titled: For those
with a hammer, everything looks like a nail.


If I understand right, yours and Bruno's solution are the same.
But, you claim some differences. I couldn't understand what you're
implying. That's why I asked some codes which may help me to
understand bit better.


Well, I suggested to use an interface.
Bruno suggested to use an abstract class (which contained a $dbobject).

Withouth that variable in the class, they would have been equal.

--
http://home.mysth.be/~timvw
Jul 17 '05 #35
Tim Van Wassenhove wrote:
On 2004-03-15, R. Rajesh Jeba Anbiah <ng**********@rediffmail.com> wrote:
Tim Van Wassenhove <eu**@pi.be> wrote in message news:<c2*************@ID-188825.news.uni-berlin.de>...
On 2004-03-13, R. Rajesh Jeba Anbiah <ng**********@rediffmail.com> wrote:

Tim Van Wassenhove <eu**@pi.be> wrote in message news:<c2*************@ID-188825.news.uni-berlin.de>...
<snip>
Unfortunately, I couldn't get what is your style (what style you're
suggesting). If you get time, could you please post a piece of your
code/style?

In this thread i suggested that an interface Session seemed more appropriate.
And that only an implementation of that interface should have knowledge
of DBObject class... As there can be implementations that authenticate
against LDAP etc (And thus not need DBObjects...)

If you want to know if i'm pro/contra OO methodology, i'm affraid i
can't answer your question. I try to pick the right tool for the right
job. Reminds me of an article that i've read, and was titled: For those
with a hammer, everything looks like a nail.


If I understand right, yours and Bruno's solution are the same.
But, you claim some differences. I couldn't understand what you're
implying. That's why I asked some codes which may help me to
understand bit better.

Well, I suggested to use an interface.
Bruno suggested to use an abstract class (which contained a $dbobject).


Why 'abstract' ? Where comes this 'abstract' from ?

I suggested to use a *concrete* class (name it Session or DBSession or
whatever) that contain a ref to a $db object. Which is exactly your
solution, minus the interface stuff which is quite fine from a design
POV (and would indeed exists in the class diagram if I was to design
this), but is just useless when it comes to implementation *in a
dynamically typed language*.
Withouth that variable in the class, they would have been equal.


They are, except that I write less useless code !-)
Bruno

Jul 17 '05 #36

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

0
by: eric | last post by:
Hi, I would like to build the inParams SQLJ sample procedure from the Development Center. if I declare a #sql public iterator SpIterat, the Development Center complains this should be in a...
1
by: Johnny Meredith | last post by:
Dear All, I have an Access database that tracks the progress of income tax audits. When the taxing authorities make a change (an "Adjustment"), I record the pertinent information in the...
0
by: BFM | last post by:
Hello, I'm just beginning a project, and looking through much documentation, and trying to figure out the best platform to develop the core of my project in/on. The project will consist of a...
4
by: Kjell Arne Johansen | last post by:
Hi How to integrate an MFC 7.0 DLL into a standard C++ application. I'm going to use an OPC Toolkit for C++ and have to interface my MFC DLLs. How do I do this? Any recommendations? Links? ...
0
by: P McGinness | last post by:
Basically, I've a JS function called ValidateForm(), which returns true or false and controls if the form submits. When I integrate this with .NET validators, the .NET always adds it's own call...
3
by: hwang2404 | last post by:
I have PHP 5.0.5 and java 1.2.2. I am trying to integrate them together. I have configure the php.ini as following: ;This must point to the location of php_java.dll. java.library.path =...
8
by: Phil Latio | last post by:
I've been creating an application over the last few weeks and generally pleased with what I have produced but one area is irritating me, form validation. At the moment the forms are simply...
5
by: Allan Ebdrup | last post by:
I have a webservice in ASP.Net 2.0, I need to store and load a xml configuration file in relation to one of the web methods in my webservice. What's the best place to store and the best way to load...
8
by: raaman rai | last post by:
i am adding dynamic contents in my website. So i also want to have a news or announcements to be dynamically displayed. But for this i need to use BBCode. But in reference to this, i dont know how...
0
by: DolphinDB | last post by:
Tired of spending countless mintues downsampling your data? Look no further! In this article, you’ll learn how to efficiently downsample 6.48 billion high-frequency records to 61 million...
0
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
1
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
0
by: Vimpel783 | last post by:
Hello! Guys, I found this code on the Internet, but I need to modify it a little. It works well, the problem is this: Data is sent from only one cell, in this case B5, but it is necessary that data...
0
by: jfyes | last post by:
As a hardware engineer, after seeing that CEIWEI recently released a new tool for Modbus RTU Over TCP/UDP filtering and monitoring, I actively went to its official website to take a look. It turned...
1
by: PapaRatzi | last post by:
Hello, I am teaching myself MS Access forms design and Visual Basic. I've created a table to capture a list of Top 30 singles and forms to capture new entries. The final step is a form (unbound)...
1
by: CloudSolutions | last post by:
Introduction: For many beginners and individual users, requiring a credit card and email registration may pose a barrier when starting to use cloud servers. However, some cloud server providers now...
0
by: af34tf | last post by:
Hi Guys, I have a domain whose name is BytesLimited.com, and I want to sell it. Does anyone know about platforms that allow me to list my domain in auction for free. Thank you
0
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 3 Apr 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome former...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.