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
oke...@gmail.com
661-349-6221
-----------------------------
On Wed, Oct 2, 2019 at 12:45 PM MB Software Solutions, LLC <
mbsoftwaresoluti...@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]
_______________________________________________
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/54e6db31-cc74-4dcf-b5e7-86d206674...@mbsoftwaresolutions.com
** 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.
