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-boun...@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]
_______________________________________________
Post Messages to: ProFox@leafe.com
Subscription Maintenance: https://mail.leafe.com/mailman/listinfo/profox
OT-free version of this list: https://mail.leafe.com/mailman/listinfo/profoxtech
Searchable Archive: https://leafe.com/archives
This message:
https://leafe.com/archives/byMID/005701d579ca$b57a8d40$206fa7c0$@wondzinski.de
** All postings, unless explicitly stated otherwise, are the opinions of the
author, and do not constitute legal or medical advice. This statement is added
to the messages for those lawyers who are too stupid to see the obvious.
