Do data files and dict files need to be in the same directory? Would this dict file be able support multiple data files with multiple index files?

Also, if the answer is no, when creating indexes, would the index file create itself where the data file is.

As an example, I have one master app within OI. I also have 14 child application inheriting from this application. Each of the 14 apps have their own data but all have the same data structure, thus 14 data file sets, 14 dict file sets and 14 index files sets fanned out in 14 different directories.

So you may imagine where I'm going. If I had one dict file set to support instead of 14, I would be a happy camper.

Chers,

Pascal Landry

Pascal,

I believe DICT and DATA do not have to be in the same directory. You could try this idea out with three directories – two for data, and one for dictionaries. If indexes are maintained correctly, then the only issue would be with changes to the index structure of a table. This would require an index rebuild in all data directories. I would like to know how this works for you. It sort of fits in with my multi-datavolume .DBT management scheme.

Gerald

Thanks Gerald,

I'll let you know how it works out.

Pascal

In theory it can work but just keep in mind that there are circumstances when it is not practical. If you happen to use the next sequence number "%SK%" this is stored in the dictionary. If you have multiple datafiles then this wont work…

John

You are quite correct. There are many files with %SK%.

Better option would probably be a form from the parent application to update dict files of the child apps.

Thanks,

Pascal

Pascal,

I can provide code for reliable assignment of sequential keys, where the control records are stored in table "CONTROLS". A separate controls table is placed in each DATA directory, with a controls depository and a master controls table for the system. This answers John's objections and then some. There are also questions about moving data between volumes when multiple data volumes are used within an application. In this case all transaction keys must be prepended with the volume identifier, so that transaction keys are globally unique. My sequential key routines handle this, as well as checking against archive tables and active tables, etc.

But there are probably some other objections to the single DICT volume which I haven't discovered. Anyone else have an idea?

Gerald

View this thread on the Works forum...