Hello UA!

I've just imagined something to be true and haven't found it yet. If this is already called something, please let me know so that I may search for it!...

What I am trying to achieve is that an end user would be able to create/delete tables & their relationships in a BE from a FE form. Also, that it could be (theoretically) infinite, but would probably only need to go about a dozen tables deep. Is there anything on this subject? Thanks UA!!! You always RAWK!

If a user needs to create/delete and manage table relations it does not sounds like an enduser need but more liike a database designer need.

Could you please describe more in detail?
____________
Bo Melin

Hey Bo!... I'm sorry for the confusing post. Yes you are right. More detail...
I'm trying to hand my DB out to a few different of my friends (in other departments on separate systems). The operational part of the DB will created only by me. But there are features that I'm looking to have an "Admin" user of each department be able to customize depending on their specific needs. What I'm hoping to utilize these tables for would be to create system folders on any server/local computer according to what an "Admin" user may need. The tables records would be names of folders and their sub-folders. The DB I created, for example, uses Word automation and saves word doc's to specified directories. The tables I'm looking to create here would then be referenced and give the correct path to utilize in my code to save these doc's.

Long winded..... yes. Worth it..... I don't know.

Rather than letting users muck about in the insides of your database--which can't be a very safe thing to do--why not design a table so that your users can enter the names of the folders and sub-folders as records in the "master" table?

George

I cannot conceive of any situation where you would want a user to be able to add tables to your db. If your entities are properly defined and your tables fully Normalized there would never be a need for structural change. This doesn't mean the end user wouldn't have full control and flexibility, it means that the control and flexibility would be handled via records and not tables.

George and Jerry,

Okay, I can see where you guys are taking this and I do like!
Is what you are talking about the same kind of concept when you set up a switchboard and see the table the switchboard manager creates??...... I can't say I've ever created a custom table that does this. How would an end user interface with such a table and what are the do's and dont's on this kind of table setup. And, what is this method called?

Thanks guys!

A reply to George too...

I found a thread on unary relationships . Is this what I should be looking for to do what you are talking about George?

No, I and George are not talking about allowing the end user to create a table (via code or otherwise). We're talking about designing your table structure such that the end user has the needed flexibility you want to give them by allowing them to add RECORDS to the tables that already exist.

What exactly are you trying to do?

Sorry once again for the confusion... I currently do not have any table doing this. I have written my folder paths in by hand in the code (which I am trying to get away from). What kind of table do you think I may need, and how would it need to be setup??? thank you!!!

Sounds like you would only need one table to capture the path(s) for use in your automation code. It is still a little unclear to me the nature of what exactly you're trying to do.

I am looking to use the MkDir function to set up folders on a server. These folders would be specified in the table we are talking about. My DB runs off of job numbers. Everytime a new job is "opened" for my company, that job receives an incremental job number (+1), on a table, from the last job that was opened in the DB. When a job is opened, a set of folders is created on a server using MkDir, awaiting paperwork automation through the DB as well. The paperwork is not only split up by the type that it is, but also, which department it was created by/for. So, the table would be used as a "job folder creator" and also would be referenced for the automated file saving.

An example of the folder structure:

Company Name---->Job Number ----> department ----> sub folders----> etc.

Subfolders contain folders such as:
Proposals
Faxes
Transmittals
etc.

I currently use the MkDir function to create folders, but it was all typed into the code manually. I'm just trying to figure out how to get it all to run off of data in a table and how it can be edited by an "Admin" end user (not myself).