If you're dealing with @GET/SAY stuff then a re-write is probably in
order. Can you actually segregate the screen stuff from the I/O stuff
and business logic? (we used to make toxic program soup in the old days!).
If so then I would suggest a staged approach:
1) separate (but don't change) a) screen stuff b) I/O stuff (use,
select, skip, locate, scatter...) and c) business logic.
If it all still works when you've done the split then next look at what
the user sees for each business function and design brand new VFP
screens to do the same thing. If that works then you have the future
option of moving your data to a back-end server and replacing dbf's with
(initially at least) cursors or views.
been there - done it - make change gradually - it's LOL AndyD
On 17/01/2013 18:28, Frank Cazabon wrote:
Hey Dan,
I would think that "harder to maintain" is very subjective as I find
them much much much easier to maintain than PRGs.
Do you have some statistics to backup your assertion that running an
SCX is slower than a PRG (I have no doubt it is, but I'd like to see
by how much).
Thanks
Frank.
Frank Cazabon
On 16/01/2013 05:17 PM, Dan Covill wrote:
an SCX is both slower in operation and harder to maintain
[excessive quoting removed by server]
_______________________________________________
Post Messages to: [email protected]
Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/profox
OT-free version of this list: http://mail.leafe.com/mailman/listinfo/profoxtech
Searchable Archive: http://leafe.com/archives/search/profox
This message:
http://leafe.com/archives/byMID/profox/[email protected]
** 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.
