Manipulating table structures 1

[wjs2]

Hello all,

I am building an application that allows useres to define their own tables, load those tables with data from any number of types of sources and begin working with them. Some of the fields within the table structure seem to be off limits unless the table is part of a database structure, i.e. captions and comments being the most notable. Anyway, this is the appearance. I'm looking for a way around this. What I am considering is the following:

Once the new table structure has been defined and 'Create table' executed, use Afields to load the structure information into an array. Manipulate the 'off limits' field contents and then save that as a memory variable '.mem' with the same name as the table. Now I can have the information for building screens and reports available programatically to other programs within the system by loading the array using 'restore from additive'.

My questions here are; have I misinterptreted something in Visual Fox and/or is there an easier way that I have just missed.

Thanks,
Bill

 

[rgbean]

Bill,
Is there a reason why you don't want to use a database (.DBC)?

Rick

 

[Mike Gagnon]

My questions here are; have I misinterptreted something in Visual Fox and/or is there an easier way that I have just missed.

Mine would be "why wouldn't you create a database also" that way you don't have to invent a work around, you'll have all the functionality you need.

Mike Gagnon

If you want to get the best response to a question, please check out FAQ184-2483 first.

 

[wjs2]

Thank you for your quick responses. Since you both seem to agree, there may in fact be no reason for the work around. When I think of databases I think of multiple tables with relationships and associated overhead. One of my primary concerns is speed. These tables can be huge. Right at the 2 gig limit. If there is in fact no overhead unless the multiple tables and relationships are present, then I can think of no viable reason to approach it any other way than using a database.

With the above information in mind, is there any reason for me not to use a database?

Thanks,
WJS

 

[Mike Gagnon]

With the above information in mind, is there any reason for me not to use a database?

Creating a database has little to do with the speed (except maybe one extra step for creating it). But since you are so close to the 2.1 gigs limit, you may to consider a redesign of your data (ie: splitting the tables and linking them with a common field) or consider a platform that permits files tables larger than 2.1 gigs (Oracle etc..)
Mike Gagnon

If you want to get the best response to a question, please check out FAQ184-2483 first.

 

[chetg]

Also, the DBC is just another Fox Table providing the extra information to define the "database container". The only overhead would be a "relational" connection to this additional Fox table to supply the database container functionality.

If you don't have any persistant relations, triggers, Views, etc. defined, the database doesn't cause much overhead at all.

Don't forget, you will have to create the table in two steps;

Open database <databasename>
create table <tablename>
Chet Gardiner

http://www.chetgardiner.com

 

[wjs2]

Thanks again for all the input.

Because of the nature of the system, I suppose an argument could be made to simply supply a copy of Visual Fox on the user's machine and turn them loose. These users, however, are not technically oriented in any sense of the word. The goal of the system is to accept varied input from almost any source, including mainframe systems, and supply a means to build the structures that give the user the ability to interrogate the data as quickly, simply and unrestrained as possible. Basically, form driven SQL's. A little more to it, but, that is the basics. From the questions and answers obtained here, it does seem to me, even though there will be no garenteed relationships, database will be a better way to go. The overhead experienced by the user, from what I am understanding at this point, would be nothing more than opening two tables rather than one. That's completely acceptable. Since the content and relationhips of the data is completely unknown prior to building the structures, building the sytem any other way doesn't seem feasible to me. Unless I'm still missing something.

Since I'm considering this approach, if I start throwing all of these tables into a single database, maybe related, maybe not, is there anything I might need to watch out for concerning this approach (performance, methods, ...)? My past experience with databses has been limited number of tables with known relationships. This doesn't exactly fit that structure. This is more like 'Here's some stuff. What can you get ourt of it?' I'm a little paranoid I guess.

Thanks,
WJS

 

[chetg]

Actually it's only 1 table more than the total number of tables.

Try this; Create a database container, add a couple of tables with all of the options you might use, long filenames, relations, indices, etc. close the tables and the database container then re-open the database container with;

USE <databasename.dbc>

then browse it. Fun stuff. Chet Gardiner

http://www.chetgardiner.com

 

[wjs2]

Thanks Chet. I'm going to go for it. What's the worst that can happen? My toenails fall off?

WJS

 

[chetg]

How did you know? Chet Gardiner

http://www.chetgardiner.com