Question: If you have a set composed of several .dbf tables, is it possible that "internal set index naming resolution" could become an issue?
Ultimately, what I'm questioning here is: Is it necessary (or even prudent) the make sure all (user assigned) index names are different at the set level (in addition to the table level?) ~ This is a difficult proposition, because you never know for sure how you may end relating sets in tables as a "application" grows.
I've begun using the following schema for indexes: Field CUSTOMERID gets assigned an index of Cstmrd__
I'm wondering if it would be a better to add a letter (representing the table's name) to try to keep the indexes unique at the set level: The index above, Cstmrd__ would become Cstmrd_c_. (where the "c" is added to designate this index has been exclusively assigned to a field in the CUSTOMERS table)
The other question is: For "performance considerations", exactly when is it necessary to even designate an index. I've read that a5 (in many instances) creates indexes automatically (regardless of what user has created beforehand). ~ My assumption is: "You should create an index anytime you know a5 may be using the field for sorting or searching." (But I've never read that anywhere, it's just my deductive reasoning on the matter.)
Explanation:
Two tables in a set contain identical named fields (very common)....
Thus, both of these tables may have uniquely named indexes (when assigned by developer) at the table level, but are now common at the set level.
Since you can end up with two "linked tables" (a set) sharing identically named fields and associated index names... Could this be an issue?
I would think this could definitely be an issue, particularly in a scenario such as this: The designation of topparent.Index_Set() on forms built on sets!
Two tables in a set contain identical named fields (very common)....
Thus, both of these tables may have uniquely named indexes (when assigned by developer) at the table level, but are now common at the set level.
Since you can end up with two "linked tables" (a set) sharing identically named fields and associated index names... Could this be an issue?
I would think this could definitely be an issue, particularly in a scenario such as this: The designation of topparent.Index_Set() on forms built on sets!
Ultimately, what I'm questioning here is: Is it necessary (or even prudent) the make sure all (user assigned) index names are different at the set level (in addition to the table level?) ~ This is a difficult proposition, because you never know for sure how you may end relating sets in tables as a "application" grows.
I've begun using the following schema for indexes: Field CUSTOMERID gets assigned an index of Cstmrd__
I'm wondering if it would be a better to add a letter (representing the table's name) to try to keep the indexes unique at the set level: The index above, Cstmrd__ would become Cstmrd_c_. (where the "c" is added to designate this index has been exclusively assigned to a field in the CUSTOMERS table)
The other question is: For "performance considerations", exactly when is it necessary to even designate an index. I've read that a5 (in many instances) creates indexes automatically (regardless of what user has created beforehand). ~ My assumption is: "You should create an index anytime you know a5 may be using the field for sorting or searching." (But I've never read that anywhere, it's just my deductive reasoning on the matter.)
~If a5 does create indexes as needed, it seems to me that it's not uncommon to end up with redundant & unnecessary indexes. And not only do they "eat up space", but they also (presumably) generate additional "overhead" while maintaining this unnecessary duplication.
Comment