As you clearly had bad experiences with Caché I can hardly argue you
out of that. All I'd ask is whether you are sure that the problems
were due to Caché or was it the application that was badly written?

I do need to take issue with one of your statements, however, namely
that Caché has "a VERY high overhead for maintenance and
administration". This couldn't be further from the truth. Caché
requires next to no maintenance at all. As an example I can tell you
the setup of our company. We have a 24x7 mission-critical Caché server
with 250 to 300 concurrent users (incl. background processes) during
standard business hours. It has several databases for different
purposes / user groups and is networked to two off-site application
servers which use the live database. For resilience the live server
has a Shadow and a Disaster Recovery server connected to it which
replicate all database activities. We also have a development server
and a Change Management server. One of my tasks at the company is the
role of the DBA which occupies no more than 10% of my time, mostly
setting up and removing development areas and refreshing the data in
test areas. If you want to call that high maintenance then please give
me an idea of what constitutes low maintenance.

Best

Wolf Koelling

americatch@hotmail.com (IT Man) wrote in message news:<113ad262.0406221055.32e0a4a0@posting.google. com>...
> Hi Sam,
>
> Cache is really heavy in the Medical field. I worked for a Medical
> Lab that was running it on several fronts, and to say the least it was
> unreliable and had a VERY high overhead for maintenance and
> administration. As it stands now it does not follow very many
> "standards" in the industry so some things don't work as well.
> Support is another issue. You may call support and get someone on the
> line that doesn't understand their own product as well as waiting for
> weeks to get a response to any issues you may have. The bad thing
> about it is that the initial setup was setup by "Cache" consultants
> and they company was still having all these issues.
>
> If you have no knowledge of Cache, then the road will be long. If you
> have a choice I would definately do a side by side comparison of other
> offerings (Oracle, MS SQL, MySQL and even Filemaker Pro) before
> committing to Cache.
>
> I am currently working on a Cache roll out for a large firm that is
> doing a 180 day eval and so far not one piece of completed code has
> been put into testing. In a way Cache is a road block unto itself.
>
> Don't get me wrong, if the product was that good, then I would think
> other companies would be trying to re-develop or "copy" some of the
> ideas that Cache uses, but you don't see that.
>
> Please, Cache Advocates, don't be angry with my comments. These are
> real experiences from someone who worked closely with the developers
> at each of these locations.
>
> samalex@gmail.com (Alex) wrote in message news:<b8d0e42e.0406180801.dc3018e@posting.google.c om>...
> > Hi all,
> >
> > We're looking at a vendor who uses the InterSystems Cache Database
> > Platform, but our IT department has zero experience with this system.
> > This software package will have a pivotal and mission critical roll in
> > our organization, so I'd like some comments on what others think of
> > this database platform.
> >
> > Mainly I'm curious how easy/difficult it is to query a Cache Database,
> > and does it use standard SQL calls like Oracle and MS SQL? What about
> > ODBC connections into the database from Crystal, MS Access, and OLAP
> > tools? Any other caviets (backup, maintenance, etc)?
> >
> > Thanks in advance for any suggestions or comments Cache.
> >
> > Sam