On 10 Jul 2014, at 11:23pm, RSmith <rsm...@rsweb.co.za> wrote: > Special Omission: I was unable to devise a query or cache requirement larger > than the machine's physical memory and thus unable to test it for function > and error reporting - but I would assume when you plan to use insanely large > cache values, some check to assert available system resources should be > included.
I once tested SQLite on a device which had a wide processor but limited memory. The testing was intended to ensure that errors in SQLite operations would lead to SQLite return codes rather than crashes in the program, which would have been a serious problem. My test programs were compiled using sqlite.h and sqlite.c as source files rather than an external library file. With two exceptions, when my operations (searches, creation of new indexes, etc.) required more memory than was available, I received an appropriate trappable error from SQLite itself. One exception was caused by a bug in SQLite which was reported and fixed a couple of years ago (actually it just disappeared because the whole routine was rewritten for another reason). In the other exception, the program crashed with an error from the operating system, something which should not happen. Repeated executions of the test program usually led to an OS-level crash, but not always the same error. The hardware technician I was working with and myself eventually decided that some part of the hardware we were using was faulty. Replacing the whole device with another whole device (the only option available to us) led to the expected trappable error from SQLite. Simon. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
