EHANCEMENTS / BUG FIXES SINCE PREVIOUS RELEASE ---------------------------------------------- Fixes in version 1.00 of MF ----------------------------------------------------------------------------- CHANGES: - mfReadList now available. 1st of a number of severe-performance functions - Modified BCARDS demo to show mfReadList speed enhancements - Fixed garbage characters at front of database. - mfInfoIndex now available - (more) documentation, nothing urgent if your familiar with MF. - minor mods to the C Header file (mf.h) KNOWN BUG FIXES: PROBLEM: The C header file specified some long and int pointers but didn't specify them as FAR pointers. This caused GPF's on anything compiled in anything but the LARGE memory model. (C only...). (Thanks to: Dan Schless) SOLUTION: We put the FAR declarations into the header file... ------- PROBLEM: *** mfDelete and mfSkip *** A word of caution about these two (when used in a 'loop'). Lets say you do an mfDelete(aRecordNum,...) and then try to do an mfSkip(aRecordNum,1,....). Since all the 'key' information about the previously deleted record has been removed, this WONT work! While this isn't a bug, it is kind of a nuisance if you aren't aware of it. SOLUTION: The general problem sneaks up like this: ' This loop should delete everything in the database that ' does NOT contain "Something Specal..." in aField... lcurRec = mfTop(...) do while lcurRec > 0 mfRead(...) if bufferRead.aField <> "Something Special..." then mfDelete(lcurRec,...) endif lCurRec = mfSkip(lCurRec,1,...) loop In order to correct this problem, you could rewrite the loop like this: lcurRec = mfTop(...) do while lcurRec > 0 mfRead(...) lOldRec = lCurRec lCurRec = mfSkip(lCurRec,1,...) ' Delete comes AFTER knowing what our next record will be... if bufferRead.aField <> "Something Special..." then mfDelete(lOldRec,...) endif loop NOTE: This did lead to discovering a 'bug' in the mfSkip code. Again, it is only 'sort' of a bug -- We did not validate that the record you are passing us was 'valid'. Being the gullible people we are, we thought you'd always pass a valid record. Anycase, the the Skip function would return a random 'record' when you called this function with a deleted value. Now, it will return MF_EOF. ----------------------------------------------------------------------------- Fixes in Version 1.00.01 BETA of MF. CHANGES: - OLD databases are not 100% compatible with the new database format. They may appear to work, but they will, more than likely, die a horrible death. If it's worth keeping the old data, you'll need to make a little conversion utility to suck the data in. Very sorry. - The FIRST record in a database is now record 1. - Improved 'bad-parameter' error checking - previously, a couple of functions where susceptible to bad task/handle/index parameters. They now kick back an error on a bad one. (As opposed to locking or GPFing) - mfInit parameters modified: Now takes a structure pointing to an extension DLL. (or, list of extension DLL's). See mf.wri (mfInit) for documentation on this feature. - User-defined keys (UDK) now supported. CSAMPLE\UDK contains a sample DLL for creating a UDK. - Minor enhancment (speed wise) for Deletes and appends... - Minor slow-down on repeated KEYS in anticipation of 'one->many' auto-indexing (e.g. previously, if you passed a index-key and it was the same as it was before, the system would not bother to check the index for the key. Now, it checks it even if the key matches...) - - - Other Stuff - - - - Severe-Performance functions pushed to release 1.1. Sorry. - Better documentation? (I don't think it could have gotten any worse...) - (Slightly) improved VB Sample. Demonstrates UDK's and multi-file support ----------------------------------------------------------------------------- KNOWN BUG FIXES: PROBLEM: GPF on Record size > 8K? SOLUTION: Yep. A sneaky bug got in and we weren't allocating enough storage for records larger than 8k. Sorry... PROBLEM: Disappearing records / Reappearing records / Reused records on appends SOLUTION: mfDelete caused alot of havoc. Inadvertently, we switched the record 'delete' ptr to a new value. When 'Record 0' was deleted, it hosed the delete tables. (Also, we killed the 'Record 0' being a record. Records now start at 1). PROBLEM: Databases that contain only an INDEX get corrupted. (e.g. You defined a database with a data size of 0 bytes) SOLUTON: Fixed. (See also WORKAROUNDS -- a Database MUST have at least 4 bytes total (inclusive of the index's)) ------------------------------------------------------------------------------ WORKAROUNDS: PROBLEM: Every database I have seems to work except a small linked list I have, is there some problem with small database? (Everything works fine until I delete something...) SOLUTION: The MINIMUM size for a record is 4 BYTES. The size of your index(s) applies towards this minimum. If you are only storing 1,2 or 3 bytes in a DB, you will get an error when you start to DELETE records. mfCreateDB has been fixed to generate an ERROR if you try to create a database that is too small. e.g.: Where recSize refers to the 'size' of the 'DATA' portion of the record. Where indSize() refers to the size of the 'index' for the index #. Valid: recSize = 0 4 bytes total indSize(0) = 2 indSize(1) = 2 Invalid: recSize = 0 3 bytes total indSize(0) = 2 indSize(1) = 1 Valid: recSize = 3 4 bytes total indSize(0) = 1