reini@tolsun.oulu.fi (Jukka Reinikainen) (07/11/88)
For a number of projects I need a PD or commercial isam-type indexed file
system manipulation tools written in C. Capabilities should include at least
these:
- 8 indexes / datafile
- read modes: CURRENT,FIRST,LAST,NEXT,PREVIOUS,EQUAL(key),
GREATER(than key) and GREATER-or-EQUAL(than key) record
- record length 1024 bytes or more
- adding/deleting indexes after file creation
- file recovery program(s) to reconstruct corrupted indexes
- (multiuser capabilities, record locking etc.)
- ported both to PCs (MS-DOS) and Unix/Xenix (sysV)
A typical application has 4 files and every file 2-8 indexes, 1-5 users
connected via PCs (MS-DOS/LAN applications) or terminals (Unix applications),
speed and reliability are needed.
For user interaction I need terminal interaction source (ported both to MS-DOS
and Unix/Xenix (sysV)). It should support terminal funtion keys and diplay
attributes, handle screen as a form which has at least 64 independent fields.
Using multiple windows is a good feature.
All suggestions are wellcome, please respond with e-mail, I'll summarize
if something striking comes up.
(*): C-ISAM is a trademark of Relational Database Systems, Inc.
Many thanks for your time...
Jukka Reinikainen reini@tolsun.oulu.fidave@westmark.UUCP (Dave Levenson) (07/17/88)
In article <371@tolsun.oulu.fi>, reini@tolsun.oulu.fi (Jukka Reinikainen) writes: > For a number of projects I need a PD or commercial isam-type indexed file > system manipulation tools written in C... Have a look at CBTREE. This is a C-language library of B+tree index and data handling functions. It seems to provide the functionality requested by the original poster (but I haven't done a checklist comparison with the original article) and is sold as C source code. As shipped, it can be built for MS-DOS (using any of a half-dozen or so C compilers) or for Xenix. Not public domain, but the source code license is not very expensive (a couple of hundred, as I recall) and you may embed the object in your product and re-sell it without royalties. I'm not affiliated with Peacock. Westmark has licensed their source code, and we are in the process of porting some database applications from Informix (costly, and perhaps overkill for this application) to a home-grown database management system based upon CBTREE. -- Dave Levenson Westmark, Inc. The Man in the Mooney Warren, NJ USA {rutgers | att}!westmark!dave
romero@mind.UUCP (Antonio Romero) (07/19/88)
In article <245@westmark.UUCP>, dave@westmark.UUCP (Dave Levenson) writes: > In article <371@tolsun.oulu.fi>, reini@tolsun.oulu.fi (Jukka Reinikainen) writes: > > For a number of projects I need a PD or commercial isam-type indexed file > > system manipulation tools written in C... > Have a look at CBTREE. This is a C-language library of B+tree index > and data handling functions. It seems to provide the functionality > requested by the original poster (but I haven't done a checklist > comparison with the original article) and is sold as C source code. > As shipped, it can be built for MS-DOS (using any of a half-dozen or > so C compilers) or for Xenix. > Not public domain, but the source code license is not very expensive > (a couple of hundred, as I recall) and you may embed the object in > your product and re-sell it without royalties. I wasn't the person working with it, so I can't comment from direct experience, but I thought I'd pass this along. About CBTREE: A company I used to work for had some unpleasant experiences with it-- to my knowledge it wasn't buggy, but according to the programmer who had to write a bunch of code to do some file manipulations, CBTREE requires keeping a number of extra files around to keep track of how files are structured, etc. After about two months working with it, she suggested we buy another file package... while CBTREE worked, she had a rather low opinion of it. I also seem to remember seeing packages on the market which offered similar capabilities, similar pricing, and kept the information of Dbase-compatible files... unfortunately, I don't have the appropriate magazine handy, or I'd do a little homework for you. I think it was a recent PC Magazine. Sorry I can't be more specific. Anyway, that's my two cents... -Antonio Romero romero@mind.princeton.edu
drew@sdeggo.UUCP (Drew Dean) (07/19/88)
In article <245@westmark.UUCP>, dave@westmark.UUCP (Dave Levenson) writes: > In article <371@tolsun.oulu.fi>, reini@tolsun.oulu.fi (Jukka Reinikainen) writes: > > For a number of projects I need a PD or commercial isam-type indexed file > > system manipulation tools written in C... > Have a look at CBTREE. This is a C-language library of B+tree index > and data handling functions. It seems to provide the functionality > requested by the original poster (but I haven't done a checklist > comparison with the original article) and is sold as C source code. > As shipped, it can be built for MS-DOS (using any of a half-dozen or > so C compilers) or for Xenix. > Not public domain, but the source code license is not very expensive > (a couple of hundred, as I recall) and you may embed the object in > your product and re-sell it without royalties. C-TREE from Faircom systems is also pretty good. As I recall, the source code lists for $395, and can be ported to about any (professional) MS-DOS compiler, UNIX, 68k boxes (they have a Mac edition), etc... Oh yeah-- the manual lists one function per page, in alphabetical order-- some people like this style, others don't. Other than using C-TREE at work, I have no connection with Faircom. Also, I should note that there update from version 3.3 to 4.1 wasn't entirely smooth, as we found some changes in the library only after we had burnt a CD-ROM...(thankfully we were able to work around the changes...) But then again, we use the low-level tools, not the high-level ISAM toolbox. Drew Dean drew@sdeggo.UUCP FROM Disclaimers IMPORT StandardDisclaimer;
watson@carssdf.UUCP (John H. Watson) (07/27/88)
I would like to add that I have been using CTREE myself and like it. I am an independent contractor now, and use CTREE in 3 different businesses. It is very well supported by the author, Bill Fairman, and his team of people, at least 3 that I have spoken to myself. The best part is that when you have a problem, you get some support right then, and no ticket numbers, with call back tomorrow if you are lucky. It is very well debugged, and if you can deal with the double buffer requirement, you will do fine. The big programming headache is that you must keep the buffer that you read the record into intact, make a copy of that buffer, update that copy, and re-write the copy. That way, CTREE remembers where the last read went, compares the two buffers to see which keys changed, and then updates its key and data files (separate files). Most of the buggs can be traced to not following this pattern. But the CTREE support staf has been very pleasant in helping me find my own buggs. I have had to call them about 3 times a year. They have a companion report writer that is great. I am using it everywhere now. It is called RTREE. It can't handle repeating records, one data record with and aray of detail records in it. This is a big problem for me, so you might want to look at RTREE before you finalize your record layouts for CTREE. I have ported CTREE to Xenix 1.0 thru Xenix 2.2, MSDOS MS C ver 4 & 5.0, Att Sys V on a 68000. All very smooth. John H. Watson rutgers!carssdf!watson
bill@ssbn.WLK.COM (Bill Kennedy) (07/31/88)
In article <177@carssdf.UUCP> watson@carssdf.UUCP (John H. Watson) writes: >I would like to add that I have been using CTREE myself and like it. >I am an independent contractor now, and use CTREE in 3 different businesses. I'll add my name to the satisfied user list. I have been using it since it was fashioned from a rib in Access Manager. I'm sure that Bill would object to that simile :-) I have only found one operating system that could not execute C-Tree code correctly, Microport V/386. The problem changed shape and moved with DOS/Merge in and out but in no case could the compiler produce working code for C-Tree or R-Tree. AT&T 386 UNIX does fine as does SCO 386 Xenix. I'm not bashing uPort about that (even though it was one of the things that made me pitch it out the door), but if you are planning on using Microport then you should forget about C-Tree/R-Tree. Personally I prefer the reverse of that logic. >a year. They have a companion report writer that is great. I am using >it everywhere now. It is called RTREE. It can't handle repeating records, >one data record with and aray of detail records in it. This is a big >problem for me, so you might want to look at RTREE before you finalize your >record layouts for CTREE. While John is correct about that you can wriggle past it by using run-time virtual sets. He's 10,000% right about keeping them both in mind when you do your design. The two get along famously but a little thought before you commit to a layout will save you some frustration. Actually, the only report writer I know of that actually _likes_ repeating records is RPG :-) :-) -- Bill Kennedy usenet {killer,att-cb,rutgers,uunet!bigtex}!ssbn!bill internet bill@ssbn.WLK.COM