I would very carefully document any changes, and the structure of any deleted fields, document the indices prior to deleting the fields; all so you can accurately recreate the database without the changes. I would run the apps and (assuming no source) add the fields and indices as it crashes based on the missing data.
Q: why by eliminating fields are the number or records reduced? Note that I am a Foxpro/DOS programmer for my company's applications running under dosemu/ubuntu, not vfp.
John
On 10/2/19 12:45 PM, MB Software Solutions, LLC wrote:
The main table in your inherited legacy application has 243 fields. Through looking at the database columns individually, you have determined that only 139 of those are used. (really!) They're of mixed types (characters, numbers, logicals, date/time, etc.). Getting rid of them takes you from a record size of 3093 down to 1982. In one instance, testing showed it reduced the size of the DBF by 1/3! Some of those unused fields have indexes on them. Let's assume I dropped the indexes on those fields.
Do you:
- do nothing...leave them as-is.
- rename them to "X<fieldname>" so that you can basically mark them
useless (to be later dropped) but have the ability to rename back to original if the app hits a snag showing a dependence on that useless field. 3. do something else I haven't considered? (Dropping them immediately is not an option as it's too radical/nuclear and offers no failsafe at time of change)
tia, --Mike
This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
--- StripMime Report -- processed MIME parts --- multipart/alternative text/plain (text body -- kept) text/html
[excessive quoting removed by server]