Re: Common Object Management/Data Access Methods

Not that I've heard anything negative, but I've never yet heard a positive 
from a DEVELOPER who had to use these COM's.  I hear lots of good things 
from people who want to be the DESIGNER for COM's for their applications. 
How it's the greatest thing and all the benefits it provides.

Maybe it's like hearing how important security is from a security officer 
and not hearing how frustrating it is from the developers who do not have 
*ALLOBJ, *SPLCTL, access to joblogs from jobs running under *ALLOBJ, etc.

Closest thing I've come to using this is practice was about 20 years ago 
on a WANG 2200.  The COM's from the TOM package were pretty low level. 
More like giving you a record chain versus however it was done in native 
2200 Basic.

I would have some performance concerns about it.  Some COM's want to be 
able to do something like
GetRecord(MyFile:MyKey);  // first position the file and read a record, 
but don't put the data into any fields.
GetField(MyFile:ThisField);  // now start putting the data into fields.
GetField(MyFile:ThisOtherField);
...
And instead of thinking how I need this data and how simply I could get 
all the data with a simple SQL cursor, I now need to do all these COM 
calls.

I don't know...  Maybe it's easier in practice with their COM application, 
than my perception.

Rob Berendt
-- 
Group Dekko Services, LLC
Dept 01.073
PO Box 2000
Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com





"Dave Odom" <Dave.Odom@xxxxxxxxxxxx> 
Sent by: midrange-l-bounces@xxxxxxxxxxxx
11/09/2004 03:16 PM
Please respond to
Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>


To
<midrange-l@xxxxxxxxxxxx>
cc

Fax to

Subject
Common Object Management/Data Access Methods






Folks, I'd appreciate a thoughtful but rapid response:

Has anyone had experience with using "objects" to create a layer around
their databases, a Common Object Module(COM) as it were, that supposedly
makes access to databases easier for end-users and applications
developers alike.   We have been approached by a vendor that says he has
built and can build around each of our divergent databases within
different database machines, a "data access COM" made up of objects
built on "object technology" similar to CORBA or Microsoft's derivative,
that will contain the necessary data access methods and logic able to
mask having to know the underlying data structures of any database and
any complex operations of any application front-ends now existing for
applications against those databases.   Once built, this COM, he claims,
 would make it be much easier and faster for applications and queries to
be built.   I'm skeptical and hear "silver bullet" talk but I'm willing
to be convinced. 

If anyone has had such an experience, how did the objects work, how
were they built, how complex a task was that, what languages and data
access methods are usually involved, what kinds of resources and skills
were involved, roughly, how long does each "object" take to create, what
are the support, performance, security, and management ramifications,
what is the "good news, bad news" of which someone should be mindful? 
I did hear ODBC mentioned by him, which gave me shivers.

Any other thoughts?

Thanks in advance,

Dave 
Arizona 
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing 
list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.