On Jan 3, 2009, at 6:45 PM, Jaysen wrote: >> MoneyWell uses an Apple database technology called Core Data and it >> doesn't like being in a package. An OS X package is nothing more than >> a folder with a special flag that keeps you from looking into it by >> accident. > > Hmm... I wonder it this might be why time machine is failing when I > have moneywell open. The little bit of tracing I have done seems to be > a write (save) while read error. I have been trying to get a better > trace with a bit clearer evidence of exactly what is going on before I > reported it. > Jaysen,
I'm not sure why this would be a problem. Both are Apple technologies and I would hope they took care of any collisions. If you do find a correlation, please let me know. > To the package vs core data file method: I thought that the data file > could be part of a package allowing for a mixed approach. I am pretty > new to OS X programing (I am a *nix person though [actually remember > building linux kernel 0.9.11]) so I might not understand the whole > thing quite right yet. My thought is that separating the receipt > storage from the actual record data will be much lighter on look up > than sticking it in a field in the transactions tables (I think the > plan you outline is avoiding the field method). > If you want to get into the real "geek speak" feel free to send me direct emails at [email protected]. This conversation would be better offline. To respond though, the NSPersistentDocument class doesn't like to be turned into a package or placed in one. It's not really Core Data getting in the way. Large data like documents should not be stored in a database, if it can at all be avoided. It's just as easy and more efficient to have a NSURL reference to a storage location and identifiers for each receipt in that container (folder). >> The three options I wanted to add to MoneyWell were to reference, >> move, or copy receipts. By default in a future release, receipts will >> be moved into the MoneyWell folder (in their own Receipts folder) >> under Application Support. You will also have the option to move this >> folder or change your receipt folder reference to a different folder. >> >> This should cover all the bases and keep from doubling storage >> (unless >> you specifically ask MoneyWell to copy the files). I'll also add some >> sort of direct capture in a future release as well. > > The only thing that I think might be a bad idea in the plan you > outline is "hiding" the files in the Application Support folder. I > don't think normal folks would be looking to associate disk usage with > a specific Moneywell file in a systems area. This could also be a "bad > taste" if someone trialed the software, added a lot of images then > decided not to use MW. How would they effectively "clean" their disk? > This it the primary advantage to the package method as i see it. > Actually, the Application Support folder but this location is just one option. Another is just a receipts folder in the user's Documents folder. The latter might be better for the purpose of leaving the receipts searchable by Spotlight. There is still no need for a package though. > Not trying to complain, just thinking out loud. I will probably not > use an image capture system. Too much work for my current needs (the > accountant manages all the business stuff). And that may not get added, but I know I have to scan my own receipts and I've tried various methods. So far NEAT Receipts has been the best but the OCR on it was slow that last time I tried. I haven't tested the new NeatWorks variation yet. Peace, Kevin Hoctor [email protected] No Thirst Software LLC http://nothirst.com http://kevinhoctor.blogspot.com --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "No Thirst Software User Forum" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/no-thirst-software?hl=en -~----------~----~----~----~------~----~------~--~---
