Hi all,

I've been working with a (potential) customer who has requested that
our product support the Faircom c-Tree Server. Up until now, we have
only worked with major RDBMS vendors ... all of which do a good job of
supporting our product's requirements, which is a mix of transactional
processing along with batch processing, reporting, etc. (i.e. - a
typical "database" app).

My first reaction was -- no way! -- Faircom's c-Tree is just a file
management library!

But then did a bit of research, and discovered that Faircom does
client-server processing, offers transaction consistency, online
backup, record locking, and a number of other features typically
associated with DBMS... i.e, it seems to be a "DBMS", although not
actually a RDBMS (it does have an optional SQL layer though).

I've googled my heart out, and read most of the documentation on the
official site, and I think I have a pretty good idea what c-Tree is
"good" for: their niche seems to be embedded systems written in "C".
That's fine. I don't know if they are the best-in-class for their
niche, but I don't care either. If you read Faircom's marketing spin,
it seems to be the perfect database platform.

What I can't seem to find anywhere is a clear statement of what c-Tree
is "not good for". Assuming that the relational data model (i.e.
referential integrity, normalization, etc.) is not essential to my app,
and TCO is not an issue, and my application is indeed written in "C" --
what kind of applications would one **absolutely not use c-Tree **?

I don't want to discard c-Tree out of hand; but we also don't want to
waste a lot of time developing support for a product that may not add
value to our application. There is no c-tree user group that I can
find, so I decided to shoot in the dark here. Has anyone out there
actually used c-Tree? Can anyone provide me with (or point me to) a
very succint list of pros and cons ... "use it here, don't use it
there" ? Where does it beat out Oracle? In what points would Oracle
win hands down?

Thanks in advance for any help!

Jim

Hello Jim,

On Fri, 2 Jun 2006 19:20:23 UTC, jimwgramling (AT) gmail (DOT) com wrote:

c-tree is a fairly full-featured database management system that
includes the source code. I used it under OS/2, two embedded
systems, and Windows. It is as good as most other database
products. The primary reasons for using such a product are
that you have the source code and that you can access your data
in the most appropriate way. They seemed to have good support
when I was using it. You can certainly stay at a revision
level if that is desired. You don't have to put up with the
release nightmares that other vendors force upon you. We
also enjoyed the ability to access the data in various methods.
We used SQL sparingly and as needed. For tables that didn't
change we used c-isam for its improved performance. That
isn't often available with other database platforms. It doesn't
sound sexy to support as most companies only 'care' about
Microsoft SQL for very obvious and wrong reasons. It is also
very cost effective.

David

Thanks David, I appreciate the info!

If it's not too much to ask, can you give me an idea of how robust
c-Tree is in terms of management tasks? ... database backup and
recovery (online? point-in-time recovery?) How about security?
Maintenance -- time to rebuild indexes, reorganize files -- can these
be issues if you have large files, high transaction rates?

I'm not asking you to rewrite the manual for me ... just looking for
any possible caveats!
;-)

Thanks again,

Jim
Rio de Janeiro

David wrote:

Good product.
I use it for the last 12 years under DOW, Windows and WINCE
applecations.
The primary reasons for using such a product are
that you have the source code and that you can access your data
in the most appropriate way (SQL - ODBC - C DBAPI - C++ DBAPI - ISAM -
LOW Level) .
The European support is excellent.
It in not expansive.
Is is very solid and if you need rebuild it is very fast.

Filippo

They seemed to have good support

jimwgramling (AT) gmail (DOT) com ha scritto:

Hello Jim,

On Mon, 5 Jun 2006 11:19:48 UTC, jimwgramling (AT) gmail (DOT) com wrote:

Our products were very reliable in terms of how the database
performed. We didn't need a terribly high transaction rate
as the product processed medical images. We had extra security
for the drives, but access to the files themselves were pretty
much open. We didn't use the protection available as it was
essentially an embedded computer (full PC network) inside an
imaging system. We didn't use the database to store our images
so database performance was just a function of the record keeping
and analysis of the images. Rebuild time wasn't bad and wasn't
needed unless we managed to corrupt the system during testing.
I was the lead developer at the time and it fell on me to keep
the database schemas and tables set up correctly. It wasn't
a big deal. I enjoyed having access to the underlying source
code when things went wrong and we needed to determine what
piece made the mistake. We did find one minor problem with
c-tree's indexing system options and got a free update for
reporting the problem and our solution. My knowledge is
also rather old (about 9 years) so I presume that there is
much more available from Faircom now. As I said in my last
note, we understood what portions of our code needed
optimization and used the appropriate level to access the
Faircom database. We generally stayed in the lower two or
three levels. SQL was used for building and upgrading the
database schemas. Performance is really up to the developer
as you should be able to make any modern processor do anything
quickly. ...just don't ask a dozen Microsoft products pasted
together with code from a beginning programmer what his
definition of fast is. I always laugh when anyone says their
machines are too slow. My curent company uses a wonderful
UI front end to generate the SQL queries for reports that
are created with a popular report generator and data stored
in Microsoft SQL. Some of the large customers have quad-CPUs
to process reports that take several hours to run. Yes, the
reports are very compute intensive, but what can a quad-Xeon
3Ghz be doing for 120 minutes just to get the SQL data.
Bascially they were tying MS SQL up in knots by trying to
process certain reports in one pass and the resulting SQL
Query was in excess of 128KB of nested queries, temp tables,
and ugly stuff. I looked at the problem for two days and
decided two SQL Queries were much better -- one to compute
the results for a temp table for the report, and one to
actually control what goes in the report. When I tested
the first pass of my solution in the lab my lowly single
2Ghz system had the final results in 47 seconds. It all
comes down to how well your tools are built and how you
choose to use them.

If I recall correctly, c-isam managed about 6,000 TPS
for analysis of our large tables on a 200Mhz CPU running
OS/2. c-isam allows you to bind a query (one time setup)
and then march through the data at a respectable rate.
Performing the same actions with a stored procedure or
a fully text based SQL request and action would be
terribly slow. You'll have to decide how much effort
to place on creating a good design and making sure the
tools are used properly. I'm pretty certain that Faircom
can handle your needs whatever they are. Politics get in
the way sometimes, so watch out for requirements (like
what database tools to use) that are dictated by management
when the developer has better knowledge of what works and
why.

Good luck,

David