| Newsgroups |
gmane.comp.windows.eccopro |
| Message-ID |
<[email protected]> |
Try it piecemeal, not all entries at once
Santiago
On 10/20/2018 18:14, trio59-computing-FFYn/[email protected] [eccopro] wrote:
>
> Hi R6
>
>
> I wanted to try an experiment with the new 'Dogs' file.
>
> I copied the 'Dogs' folder, opened a new file and pasted it into the
> new file and saved it.
> Ran mem. reporter and got:
>
> 23,564 Items
> 23,770 View Li
> 458 Pointers
> 41,757 free
>
> Was going to try to import my Phonebook folder from 'Dogs' but when I
> went into the new file's Phonebook I got the dreaded:
> 'Unable to ccomplete command, low memory condition detected!'
>
> Hmmmm......
>
>
>
>
>
> Thursday, October 18, 2018, 11:36:55 PM, you wrote:
>
>
>
> Hi Rick, sorry but my availability here is spotty at best.
>
> BTW... everyone is free to call me R6 for short. :)
>
> There is a lot to be said about this. Not sure I can say it all, but
> here are some general thoughts that come to mind.
>
> * I think there are two major parts to this operation. Part 1 is
> about how you want to divide your file up. If, for example the file
> is about Dogs, Cats and Birds, maybe you want a separate file for
> each. I would have a clear idea of how I want to break it up before I
> start. That's something you will need to determine.
>
> Part 2 is the technical part. Here are some thoughts on that.
>
> * The first thing I would do is to try my best to make sure I am
> working with an uncorrupted file. Why? Because the best way to split
> up the file is probably to base all three files on the original and
> subtract (delete) what you don't want from each file rather than
> adding it to a new file. That may save you a lot of work and
> potential error. So you want to be sure that file is intact.
>
> * Best way I know to do this is the File/Recovery routine we
> discussed. However, there is an important nuance here. You mentioned
> it used Method 1 to recover the file. That's a good sign. BUT... I
> would run the recovery again and watch the screen very carefully.
> Sometimes it runs Method 1 for a while and then suddenly runs Method
> 2. And sometimes the Method 2 message only flashes for a second or
> two. So watch the screen very carefully the entire time the recovery
> is running to make sure the dialog never mentions Method 2.
>
> If you only see Method 1 again, then its a pretty good indication that
> the file should be okay.
>
> *IMPORTANT* When you run the recovery, make sure it's a file you
> *have not* already run it on (i.e. use one of the recent backups
> before you ran it before.) Otherwise this test is invalid.
>
> * I'd also want to get some kind of better handle on why your file is
> so big. Until that can be explained I wouldn't be completely
> comfortable splitting it up and going forward with it (versus starting
> with all brand new files). Do you tend to use a lot of Text folders
> and type a lot of text into them? Do you have a lot of items that
> include a very large amount of text? If you've eliminated the
> embedded files, that's one of the few explanations I can think of that
> would make your file so large even with the full boat of ~16k items
> that it has. There would have to be a huge amount of text, not just a
> few words for each item tree.
>
> *This next part you may or may not not like so much, but I will
> explain my reasoning. I would get and install Slang's Ecco Extension.
> One reason why is that you can run a recovery on that same recent
> backup and it will preserve almost all of your formatting and
> configuration -- whereas the native Ecco you are using now will lose a
> lot of formatting and configuration upon running that recovery. The
> recovery process with EE also has a number of other improvements that
> make it superior to the one native Ecco has. It's pretty solid. In
> addition, EE will take your Ecco to a new level. Even if you don't
> use the more advanced features, it fixes some bugs and it is there for
> you if you want to get deeper into it.
>
> This is just a suggestion, if you are happy with the file after the
> recovery the way it is, it isn't necessary.
>
> * Assuming the file checks out good above and you are ready to start
> splitting it up, I think that no matter how you decide to proceed you
> will have to do a lot of manual manipulation of your data. After all,
> there really isn't a any good automated way to avoid having to make a
> decision about every item as to which file you want it to be in.
> (depending on how your file is structured, however, you may be able
> to use sorting and filtering to allocate groups of items to a
> different file all at once). But here are some thoughts to maybe help.
>
> * I might start by deleting everything you can find that you don't
> need if you haven't already done that. Your file is indeed on the
> upper edge of the safety zone and you don't want it to become
> unreadable, The more items you can delete the better the chance of
> avoiding further complications.
>
> * Consider creating a checkmark column for each of the files you want
> to create (for example a column each for Dogs, Cats and Birds). Then
> you can just check that column for each item you want to include in
> each file. That will make it easy to delete Dog related items from
> the Cat file, etc. Then create 3 copies of your file and filter by
> these columns to show the things you want to delete and delete them.
> Each of the 3 files will then include only the items you didn't delete.
>
> I realize that it might be way more complicated than this. For
> example, what if you have a TLI about Dogs, and an SLI about Cats?
> But this is just an overview of some related thoughts. Hopefully,
> your file is such that there are not a lot of complications like this.
> A lot depends on your decision about how you want to divide it up. A
> careful choice in that regard can make a big difference in how easy or
> hard it will be,
>
> Hope something here is helpful.
>
>
>
>
>
> <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient>
> Virus-free. www.avg.com
> <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient>
>
>
> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>