wiseman@tellab5.tellabs.com (Jeff Wiseman) (03/28/90)
The following is the response that I sent to an idividual who had a problem with the DB DIRTY, Error=18 situation in Dollars and $ense v4.1c. I spent so much time on the note that I felt it might be useful to others. Please note that these are items that I have derived from much guessing talking and data entry, if there is something incorrect or could be clarified further, I would really appreciate hearing about it. Anyway, for what it's worth ..... --- > I just ran into one of the "Database Dirty" and Error 18 "An error occurred > in GetATrans... in D&S v4.1c. I talked to "Ron" from Monogram who said > 5.0 will fix this, but in the mean time try adding 4 new accounts: I have not ever tried the 4 account trick but I do know that the "save as" usually will not correct the problem although it may help to prevent it from happening...it also tends to compact the database some thus taking up less room. I will tell you how I deal with this "bug" but you may or may not like it :-) > got more errors, until frozen mac or system errors. From the gist of your > message on comp.sys.mac, it seems that you are familiar with such errors. I am familiar with such errors in that I feel I have given my progam a real workout. I have 58 accounts leveling down 4 steps in some cases. I carry dynamic liabilities accounts (ie. loans to others) that change constantly. All of this is for the purpose of budgeting. I created a list of program bugs that was about three pages long, many that Monogram did not know about. (by the way, please don't ask for the list, I never got it put into the system from hand scribbles. I had promised Ron a copy a long time ago and now that 5.0 is imminent, it doesn't seem worth the time that I don't have anyway :-( ). > Current system: MacPlus (2.5megs), System 6.04, DeskTop Mgr, Lots of INITS. I don't think there should be any problems here although I have not used 6.04 (I use 6.02). > I have about a two week old backup, but I don't want to fool around with > it unless I absolutely have to. > > Any help would be greatly appreciated. Is there something I can avoid doing > so that this will not happen again? The two week old backup in a sense is part of our problem and there ARE things which seem to help avoiding the problem. Let me see if I can bring this all together now... I have only succeeded once in fixing the DB dirty problem and beleive it or not it was through the "Revert to last saved" type function (file menu). The only way that I have been able to deal with this is as follows: 1) Don't do anything unusual with transaction entry or editing functions. This product has a lot of bugs in it that to me (a real time software engineer of 16 years for what it's worth :-) is an indication of poorly structured software. However, the feature that makes this product so nice is it's highly structured INTERFACE. eg. you can enter a transaction as a cash transaction dispersed to an expense account or a cash expense dispersed to an asset (cash)account. However, this product evolved from version 1.x which (I believe) only supported it in one direction, similar to many other programs on the market (eg. MacMoney). In other words, the internal structure doesn't support the external. Bugs exist more in the areas that externally were not supported by the original database. But I'm rambling... Avoid things like modifying transactions from an expense account, even though you are supposed to be able to do it. ESPECIALLY if you have created some odd-ball transactions (eg. get $20 from asset A and put $10 into asset B and increase expense C by $6 with flag XXX and increase C again (that's right, two dispersals to the same account - it CAN be useful) $4 with flag YYY. This can get you into trouble. Another good rule is just enter transactions and modify from asset and liability accounts only where possible. again ESPECIALLY when using descriptors! One that is almost guranteed to mess you up is the good'ol paycheck. Lets say you set it up as a transaction on an income account (increase). It would typically disperse to several expense accounts such as taxes and medical contributions, etc. There will also be an INCREASE to an ASSET account (such as savings if you have direct deposit). It is EASY to forget and do a new transaction on "SAVINGS" and then hit your paycheck descriptor since it is an increase to your assets. But the descriptor was set up for a non-asset/libility account. I have yet to see this NOT create a DB dirty condition! In summary, perform all transactions manipulations from (first) asset accounts and (second) liability accounts. You can occasionally break this "rule" and get away with it if you also follow the next two rules. 2) Keep your data clean and 3) Maintain close backups based on clean data. These last two points only seem to be possible through the "save as" function. I use a technique that is a bit wastful of space but is historic from my floppy only days and allows me to revert back to that technique if I were to loose my hard disk. You may be able to develop a technique of your own based on the same principles. On my hard disk I maintain 3 files in a directory by themselves. Call them "budget 1", "budget 2", and "budget 3". I also have three floppies corresponding in name. (ie. floppy #1 is "budget 1", etc.) Each contains basically a duplicate of the corresponding hard disk file. (eg. floppy "budget 1" has a single file on it called "budget 1", (usually) identical to the hard disk file with the same name). The folder on my hard disk with the budget files in it is always set up to "view by DATE" (or time, whatever) so that the NEWEST or most recently updated file is ALWAYS at the top of the list. I will explain in a moment why but this file (ie. the one at the top of the list) corresponds to a copy of the last backup). Anytime that I sit down to do budget, I go to this folder and open the file at the TOP of the list. This file has been compacted during backup and cleaned using the "save as function".. More to follow :-) As I do my entries, I will occasioanlly do a command-S (straight "save" command) thus updating the hard disk file and moving it forward in time from its backup copy that was previously recorded on floppy. At the end of a session (usually 1 to 2 times a week) and after doing a command-S I then do a "save as". For example, if the file I was working on was "budget 2" the save as command would produce a dialog box saving to file "budget 2 (backup)". You change the name to budget 3 and redirect the ouput to floppy "budget 3" thus overwriting your oldest session (3 back) backup. This creates a backup of the session just completed but IN A CLEAN, COMPACTED form. You then exit D&S and go to the floppy (eg. "budget 3") and COPY by finder, the new compacted file back into the hard disk folder, overwriting the file of the same name (ie. the oldest session backup, in this case "budget 3"). Doing this provides THREE main benifits. First you get a series of SESSION oriented backups that protect as many as 3+ sessions at a time. Secondly, since you always start a new session with a COPY OF YOUR MOST RECENT BACKUP, you actually get to check that your backup was good! If a failure had occurred during ANY of the previous sessions or during their "save as" type backups, you will be able to see it and go back and correct it immediatly. But lastly and more important, everytime that you start a new session, you are doing it with a SORTED, COMPACTED, AND CLEANED DB file! It seems that a lot of DB bugs are associated with the DB being organized in a haphazard fasion. By starting a session with a "saved as file" that internally must be better organized, you are far less likely to run across these bugs. Since I begain using "saved as files", I have not run into the DB Dirty condition for over nearly a year now (for what its worth). Note that if you only have a quick session (eg. you just want to sit down and enter 3 or 4 visa receipts and/or you don't have time to do a save as since with a year and a half's transactions it can take 10 minutes) you can backup by simply doing a finder copy to a floppy and then when you resume your hard disk session, just forget the floppy. Anyway, hope this gives you some ideas. Too bad this program has the problems it does because from a feature standpoint it is really excellant IMHO. -- Jeff Wiseman: ....uunet!tellab5!wiseman OR wiseman@TELLABS.COM