Dale Pond wrote:
"In the end I do not see any reason to redesign the collection - way
too much data for that now. If the HyperSearch stack can be made to
work like it did in HC I would be quite happy."
Dale,
I might as well start with the bad news:
You will not be able to get what you want with a simple HC/Rev
conversion.
Rev has many virtues but it just does not handle large number of
records well - in stack form. We found this out the hard way;
operations on large stacks that took a few minutes in HC would take
hours (many hours) in Rev. The problems become significant around
5000 cards and became exponentially worse as the number of cards
increases.
The size of large stacks also increase significantly when imported
into Rev.
Big stacks, converted to Rev, take longer to open, longer to save,
and longer to close than they did in HC.
There are other ways to handle this data in Rev (text files come
immediately to mind - and they are faster and smaller than stacks).
There are many talented people on this list who could help you make
this conversion. If you wish to do this work yourself - with some
guidance, you might consider a mentoring program using your data
(perhaps with the Master Mentor, Jerry Daniels).
Fortunately the data (the most important part of your collection)
could be imported to the new framework via script - there should be
minimal manual work required.
Regarding the "idle" commands: I found them in the HyperSearch stack
you posted recently. Idle commands are a bad thing for a variety of
reasons and should be avoided (with Rev's ability to send a command
at some future time, they just are not needed in Rev.) For example,
one place your stack used an Idle command was to periodically compact
the current stack; compacting was critical in HC, HC appended data to
the file when it was changed and only consolidated the information
when the stack was compacted (basically, all of the data in the file/
stack was re-written to a new contigueous stack). If this was not
done periodically in HC, the stack's directory would loose track of
parts of the file - and the stack would become corrupted. Rev does
not have this problem - and does not need regular compaction.
By changing the framework for your information you can eliminate many
workarounds that HyperSearch used to accomodate HC. You would get
more speed, a more convenient interface, reduced storage
requirements, faster backups, more flexible searches, etc.
I sympathize with your desire to do a simple conversion. When I
started with Rev in 2001 I had almost 15 years work in HC-based
business systems, used daily by thousands of people - and all "I"
wanted was a simple conversion. We tried.
In the end, it was easier (and better) to rebuild the framework in
Rev. The problem ended up being an opportunity.
Sincerely,
Paul Looney
_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
