>When you say "array of db tables" what exactly do you mean?
Sorry, my function descriptions are a little terse (intended just for myself at this point really). Each of them describes what the functions returns. So that function returns the list of tables as an array.
As I said, I want to "contain" the mysql resource types within this class, so that other calling classes need merely deal with (more conventional) arrays. So here, for example, I convert the query result resource to an array and just return that.
The resource types that Mysql deals with already, in my opinion, perform the job of encapsulation to a fair extent (especially the connection link id resource), so I don't feel the need (since I'm only dealing with the one db type at this point) to wrap a class around it. I don't have access to PHP 5, so for now I simply return error messages (again, from the link resource) if they arise and if the calling class/scripts requests it (typically after a FALSE return value from one of this class's functions.
>Your object is a connection object and an iterator object and an error >handler all in one.
>This needs some refactoring.
As I've said, if things get hairy enough I WILL separate out the object-handling part. It just works so closely with the db connection that for now I've got it integrated. I don't have a problem with the rest of it. For now, I'm just trying to get this baby off the ground..
You know, to some extent, I guess, I'm going back in my thinking to NeXTStep's "Enterprise Object Framework", which allowed programmers to use objects with databases without having to deal directly with the database itself. (Yes, I have been coding with oops for awhile...). That system now appears (along with Nextstep->OSX) as Apple's Webobjects.
NOT that I am attempting anything QUITE so ambitious or grandiose, MERELY the ability to (as I said in my original post) convert PHP objects into corresponding mysql tables. Is that REALLY such a complicated, abstract concept, (PatrikG)?
I'm not certain why you suggest the "decorator" (that just seems to be another way to sub-class, no?), PatrikG, (although I'm impressed with that patterns website!), but the DAO approach IS much closer to the mark. My naming convention in some of my functions might be confusing: several of them accept both objects OR arrays as arguments. I actually find it easier to parse (etc.) an object's vars by casting it to an array. But, as I say, the SPECIFIC issue I'm dealing with is that of writing/retrieving OBJECTS, which, of course, might themselves CONTAIN arrays. So I need a way to represent ("map") both types to tables (I'm finding arrays trickier than the objects, interestingly enough..).
Now Nielsene is on a similar track to me, I THINK..
But I think (need to study your code some more..maybe STEAL some of it!

) it MIGHT differ (and think I definitely differ from DAO) from the standpoint that I seem to be approaching it "backwards". By that I mean that DAO seems to concern itself with transforming a database into classes/objects by examining the tables (and relationships) and producing corresponding classes of objects. I'm going about this by letting the objects (not the database) drive the design. I can start with an empty database, begin passing it objects, and tables (and relationships, I'm hoping..) will be generated. So really I am letting PHP "drive" things (that should please you, PatrikG). I guess instead of DAO I'm OAD (not to mention ADD...)

The challenge (or obstacle, possibly) might be generating tables and relationships that make sense for my class AND are useful within the mysql database/engine itself (hence I'm concentrating on db integrity, though it's starting to get a mite baroque).
If this thing works out, perhaps ultimately I could abstract it out enough that it could splice with objects such as, for example, the PEAR:DB class (which IS nice for the way it handles so many db types). I'm also awaiting the release (and my host's adoption of..) PHP5 to help streamline things a bit hopefully.
Thanks all,
Sander