I am now thinking of moving to Rev and you mention 5500 cards come close to the limit. This is indeed very, very bad news for me. I rushed to check the Rev documentation and it says that the maximum number of objects in a stack is "unlimited." Admittedly I'm getting confused. The stack in question has now 1.2 MB. Is this too much for Rev under OS X?
No, not at all. I should explain more. There is no theoretical limit to the number of cards, and you can create as many cards as you like within the limitations of your hardware and RAM. There are two things, however, that make very large database stacks less practical in Revolution than they were in HyperCard.
The first is that HyperCard is disk-based; you can have very large stacks that run in a very small amount of memory because each card loads as needed. Revolution loads the entire stack into RAM at once, which makes it run much faster, but which also requires that the user have as much RAM as the stack takes on disk (plus a little more for the engine.) It doesn't sound like memory is a problem yet with your stack, though.
The second thing that is much different is the "find" command which is commonly used in HyperCard to search a card-based database. HC used its famous "hint bits" to create an incredibly fast search. Revolution does not use hint bits and Rev's card and field searching is noticeably slower than HyperCard's. This was the primary limitation I was talking about. If you are using typical HC search routines to look up words in your dictionary, you may find in very large stacks that the "find" command becomes too slow to be suitable. Under these conditions, it is usually recommended that MC/Rev be used as a front-end to a more traditional, dedicated database.
However, if you are using a custom indexing routine rather than using "find", you may be just fine.
Scott Raney used to recommend that stacks not go above 3-5,000 cards or so before being moved to a more formal database. That isn't a hard number, just a suggestion. I always took it to mean that performance slowed enough after that to make a difference. Speed would also probably depend on how many objects and backgrounds are in the stack
Finally, try setting the HCAddressing property to false. You don't need it in Rev. I don't really think this will make all that much difference, but I usually do it anyway. It does affect some aspects of stack behavior sometimes, and you don't need it to be true when working in Revolution.
I was not aware of this property and happily followed your suggestion. So far, saving works fine and hopefully stays that way.
So that made the delay go away? That's good to know. :)
-- Jacqueline Landman Gay | [EMAIL PROTECTED] HyperActive Software | http://www.hyperactivesw.com _______________________________________________ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
