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:
1. do nothing...leave them as-is. 2. 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 ---
I would drop the indices and use option 2 to rename the fields to drop them after operations demonstrates that they are useless. The reduction in record size would be well worth it.
----------------------------- Michael Oke, II okeind@gmail.com 661-349-6221 -----------------------------
On Wed, Oct 2, 2019 at 12:45 PM MB Software Solutions, LLC < mbsoftwaresolutions@mbsoftwaresolutions.com> 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.
- 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]
Hello.
You must keep in mind that renaming the fields is the same as dropping them : if there is a risk of use, you'll get an error.
So the only problem, if you drop them, is to remember the genuine fields names and indexes : why don't you simply make an empty copy of the dbf to trace them ?
USE <yourtable> COPY TO <whatever> FOR .F. WITH PRODUCTION
Gérard.
On 02/10/2019 21:57, Michael Oke, II wrote:
I would drop the indices and use option 2 to rename the fields to drop them after operations demonstrates that they are useless. The reduction in record size would be well worth it.
Michael Oke, II okeind@gmail.com 661-349-6221
On Wed, Oct 2, 2019 at 12:45 PM MB Software Solutions, LLC < mbsoftwaresolutions@mbsoftwaresolutions.com> 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.
- 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]
Hi Gérard,
Renaming them might seem like dropping them, but in my case the values are still there. If I find "oops, I should not have deleted X_Field1" then I can just rename it back to Field1 and all of the values are still there. Dropping the column means there's no safety valve...those values are then GONE.
--Mike
On 10/2/2019 4:22 PM, Gérard LOCHON wrote:
Hello.
You must keep in mind that renaming the fields is the same as dropping them : if there is a risk of use, you'll get an error.
So the only problem, if you drop them, is to remember the genuine fields names and indexes : why don't you simply make an empty copy of the dbf to trace them ?
USE <yourtable> COPY TO <whatever> FOR .F. WITH PRODUCTION
Gérard.
On 02/10/2019 21:57, Michael Oke, II wrote:
I would drop the indices and use option 2 to rename the fields to drop them after operations demonstrates that they are useless. The reduction in record size would be well worth it.
Michael Oke, II okeind@gmail.com 661-349-6221
On Wed, Oct 2, 2019 at 12:45 PM MB Software Solutions, LLC < mbsoftwaresolutions@mbsoftwaresolutions.com> 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:
1. do nothing...leave them as-is. 2. 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]
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]
The number of records is not changed but the size of the table is.
John
John Weller 01380 723235 07976 393631
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
Hi Mike, 243 - 139 makes 104 useless fields. Plus their indices. Good catch! Question remains: why are there 104 seemingly useless fields? Are those fields completely blank / empty? Maybe they have been added for some planned but never finished additional module. Maybe they are a leftover from some import / update mode. Maybe they are used from a different application, which you haven't seen yet...
I once had a similar scenario, where those fields had names with an incrementing number like "field_c_1", "field_c_2", "field_d_1", "field_d_2" etc for several fieldtypes. It was their way to get customizable fields into a vertical market application. For each customer installation they could use those dummy fields for different customer demands. The bad thing with that code was that a simple "code reference" search for the exact fieldnames didn't got any results, since they built the resulting fieldnames in a loop like "field_" + cType + "_" + str(i,1,0) and stored them then in an array.... Yea, it was damn flexible, but definitely not for easy understanding! :)
As to "what to do": go with option 2 and let them run their app again. If it bombs on some fields you'll then know fore sure that your search wasn't perfect :) Just rename them back, without any hassle to merge old saved data with the current tables.
wOOdy
-----Ursprüngliche Nachricht----- Von: ProFox profox-bounces@leafe.com Im Auftrag von MB Software Solutions, LLC Gesendet: Mittwoch, 2. Oktober 2019 21:45 An: profox@leafe.com Betreff: Another refactoring question regarding unused columns in a DBF table
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:
1. do nothing...leave them as-is. 2. 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]
-
Gérard LOCHON -
John R. Sowden -
John Weller -
juergen＠wondzinski.de -
MB Software Solutions, LLC -
Michael Oke, II