Either add a trace-log which shows the flow of the program (entering, exiting methods, database commands accessed).
It's not so simple that when you send the program to him in the field, it's a release build and when you test you are using a debug build? On 4/17/07, Joel Cochran <[EMAIL PROTECTED]> wrote:
I've had him sit beside my in my office and attempt to recreate it, both using his device and mine, but it never happens. Actually, I did get it to happen once on his machine, but I was not connected to my PC, so I connected and tried to recreate it through DEBUG but could not. The last time it happened in the field, I had him stop using the device and bring it to me so that I could see the Stack Trace (which I sent to the list). With neither his device nor mine can I recreate the problem in DEBUG. It is very frustrating. Thanks, Joel On 4/17/07, Jonas Sandman <[EMAIL PROTECTED]> wrote: > > What is the guy on in the field doing that you are not? Are you using his > device for the testing? > Since it takes minutes for him to encounter the error it can't be that > hard > to recreate. Follow him around for an hour or so and see how he uses the > program. It could easily be something he's doing that you aren't... > > On 4/17/07, Joel Cochran <[EMAIL PROTECTED]> wrote: > > > > The saga continues... > > > > I was very excited by the idea that there was something wrong with the > CF > > Card. The theory fits all the facts: it explains why the original > > database > > threw unspecified errors, it explains why now SQLite is throwing errors, > > it > > explains why I can't reproduce the problem in house or on my > machine. It > > just seemed to explain everything, so yesterday I went out and bought a > > brand-spankin' new SanDisk CF card. I loaded it up with the database, > > installed it on my tester's machine, and this morning it went back out > to > > the field for testing. > > > > Within minutes, he encountered the same error. > > > > Now I just don't believe the problem is with the card, so I feel that I > am > > right back at square one. I'm really at my wits end and don't know what > > to > > do next. I am going to go ahead and install the database on the device > > memory instead of removable media, just to test it out, but I have no > > faith > > that it will change anything. When that fails, I will send the tester > out > > with another device entirely, but again I expect the same results. > > > > I'm convinced now that the problem is with the application architecture, > > but > > I have no idea what to look at anymore. I've stared and fiddled with > this > > code so much that I'm ready to throw in the towel. But since I'd like > to > > keep my job that isn't an option. If I had hair, I'd pull it out. > > > > Any help at all would be appreciated. > > > > -- > > Joel Cochran > > > > > > > > On 4/13/07, Michael Ruck <[EMAIL PROTECTED]> wrote: > > > > > > Unless things have changed recently, the following should still be > valid > > > for > > > > > > Windows Mobile/Windows CE devices: Usually these devices do not power > > off, > > > but > > > stay in a standby state where the memory is always powered. Check if > > > that's > > > the > > > case with your system and move as much as possible into RAM or a RAM > > disk, > > > if that > > > feature is provided by the windows mobile kernel built for your > device. > > > > > > If that's not possible, I'd suggest replacing CF cards with micro > drives > > - > > > these > > > are regular hard drives in a CF card format. I'm not up to date on > > storage > > > space, > > > but should be sufficient for your needs. > > > > > > To test the cards I'd put them in a card reader format it and fill it > > > completely > > > up with zeros. When a flash card erases a byte, it sets all bits to > ones > > > and > > > upon > > > write clears those, which need to be zero. So to test all bits you > > really > > > need to > > > zero out the entire card. This will also give the controller in the > card > > a > > > chance > > > to remap bad sectors with spares. Finally you determine the file size > of > > > the > > > card, > > > when you receive the first write error. This is (approximately) the > > number > > > of bytes > > > the card can store (at that point in time) and falling. > > > > > > It seems some cards even return "read errors", when they hit a > defective > > > sector > > > upon read. Maybe the actual error code just gets lost/mangled on the > way > > > up > > > and the > > > actual error is just a simple read error ;) I've seen reports about > this > > > with some > > > digital cameras, which would not even let people view the pictures > taken > > a > > > minute > > > ago. > > > > > > Mike > > > > > > -----Ursprüngliche Nachricht----- > > > Von: John Stanton [mailto:[EMAIL PROTECTED] > > > Gesendet: Freitag, 13. April 2007 23:44 > > > An: sqlite-users@sqlite.org > > > Betreff: Re: [sqlite] Still getting "Insertion failed because database > > is > > > full." errors > > > > > > You might find some joy in the baby disk drives such as installed in > the > > > original ipods. > > > > > > Can you substitute RAM with a battery backup if the memory card is > > always > > > in > > > the device? > > > > > > Joel Cochran wrote: > > > > Thanks John and Dennis, > > > > At least now I have something to look at. I will look into the CF > > > > problem next. > > > > > > > > The database itself gets generated on a PC and then transferred to > the > > > > CF Card. During testing and development, this could have been 20-30 > > > > times a day, constantly erasing and recreating the existing DB. We > > > > have also sent large numbers of JPGs along with the database in the > > > > past (there are none now, but have been before). So these cards > have > > > > been written over a lot, perhaps that is the problem. > > > > > > > > I think to test this, I will send the device back to the field with > a > > > > brand new card and see if the problem persists. If the user can go > > > > several days of normal use without the problem, then I'll be > convinced > > > > that it is the card. Out of curiosity I just checked the CF cards > > > > we've been using: on the development machine (which has NEVER shown > > > > the error) I have a SanDisk CF Card. On the Testing machine that is > > > > having the problem, there is a PNY Technologies CF Card. I wouldn't > > > > be surprised if the SanDisk card isn't simply better than the PNY > > > > card, so there is something else to consider. > > > > > > > > Once actual field use begins, the database will be replaced every > week > > > > or so, along with a fair number of images (like 100-300 a > week). The > > > > purpose of the application would have every record in the database > > > > being updated and some new ones created. And it would be that way > > > > week in and week out, essentially forever. We may eventually port > it > > > > over to very small Tablet PCs, but right now it is all Windows > Mobile > > > > 5. This is one of the reasons I went with SQLite, so that down the > > > > road I wouldn;t have to reinvent the database piece of the software > > > > for a different platform. > > > > > > > > Given all this, I will definitely look into the link Dennis > sent. The > > > > company is not going to be happy replacing CF cards all the time, so > > > > if that can extend the wear then it will be welcome. > > > > > > > > Thanks a lot, > > > > > > > > Joel > > > > > > > > On 4/13/07, Dennis Cote <[EMAIL PROTECTED]> wrote: > > > > > > > >> > > > >> Joel Cochran wrote: > > > >> > > > > >> > Or do you mean over the course of the lifetime of a CF card it > can > > > >> > only be used so much? That might apply to this scenario, these > > > >> > cards have been written over continuously for the last 6 months. > > > >> > > > > >> Joel, > > > >> > > > >> Yes, that is exactly the problem. You should look at using a flash > > > >> file system such as http://sourceware.org/jffs2/ that uses "wear > > > leveling" > > > >> algorithms to spread the writes over all the flash devices blocks > if > > > >> you are writing often. > > > >> > > > >> HTH > > > >> Dennis Cote > > > >> > > > >> > > > > > >
