tensmekl@infonode.ingr.com (Kermit Tensmeyer) (01/24/91)
Has anybody come up with either a C++ base object for manipulating Oracle tables or a good C data/method hiding module source set. One of the problems with dealing with Pro*C and C++ is that each set thinks that it's the only preprocessor to Old C. Has anyone come up with a good set of makefile rules for dealing with this combination? Thanks for the help. -- Kermit Tensmeyer | Intergraph Corporation UUCP: ...uunet!ingr!tensmekl | One Madison Industrial Park INTERNET: tensmekl@ingr.com | Mail Stop LR23A2 AT&T: (205)730-8127 | Huntsville, AL 35807-4201
davidm@uunet.UU.NET (David S. Masterson) (01/25/91)
>>>>> On 24 Jan 91 03:43:12 GMT, tensmekl@infonode.ingr.com (Kermit Tensmeyer) said:
Kermit> Has anybody come up with either a C++ base object for manipulating
Kermit> Oracle tables or a good C data/method hiding module source set. One of
Kermit> the problems with dealing with Pro*C and C++ is that each set thinks
Kermit> that it's the only preprocessor to Old C. Has anyone come up with a
Kermit> good set of makefile rules for dealing with this combination?
In general, put the SQL calls in C ONLY! functions and build your C++ code to
call these functions at an appropriate time. Mark the functions as 'extern
"C"' in your C++ code an compile everything normally into object modules. The
last step would be to link the SQL/C object modules with the C++ object
modules and let the linker resolve everything. No hassling with trying to get
a preprocessor (say Pro*C) to recognize something it wasn't set up for (C++
code) as each preprocessor only works on stuff that it knows. Then you
establish file naming conventions like .SC for Pro*C files and .CXX for C++
files and define your makefile rules accordingly.
--
====================================================================
David Masterson Consilium, Inc.
(415) 691-6311 640 Clyde Ct.
uunet!cimshop!davidm Mtn. View, CA 94043
====================================================================
"If someone thinks they know what I said, then I didn't say it!"rec@indetech.com (Rick Cobb) (01/28/91)
I've tried to reply by mail, but keep getting "tensmekl... User unknown" Apologies for the blatant commercialism.... In article <1991Jan24.034312.20923@infonode.ingr.com> you write: >Has anybody come up with either a C++ base object for manipulating Oracle >tables or a good C data/method hiding module source set. One of the problems >with dealing with Pro*C and C++ is that each set thinks that it's the only >preprocessor to Old C. Has anyone come up with a good set of makefile rules >for dealing with this combination? > >Thanks for the help. > > >-- >Kermit Tensmeyer | Intergraph Corporation >UUCP: ...uunet!ingr!tensmekl | One Madison Industrial Park >INTERNET: tensmekl@ingr.com | Mail Stop LR23A2 >AT&T: (205)730-8127 | Huntsville, AL 35807-4201 Yes, we have a way to do this. Since we're an OLTP shop, we use a class generator rather than a base class. The generator provides a class for your table that supports insert/update/delete/etc., allows you to set up multiple where clauses, provides an iterator across the return set for queries, etc. It is possible to use it to provide "lazy joins", where foreign key relationships aren't computed until you ask for that particular instance variable. In addition, other optimizations and runtime checks are performed: o special methods are required to set primary key fields. o updates which won't change any values aren't sent to the database o assignments to uninitialized or unselected tuples are caught. o etc. The mapping between C++ types and PRO*C types for the instance variables is managed by a kind of class called a "mapper", which can be used to handle translations like Oracle date/time to UNIX date/time, etc. We provide an extensive library of mappers with the product. We currently support it for PRO*C for Oracle 6.0.{26,27,30} on a variety of Unix machines. We sell this as one of the components of our "iTRAN" transaction processing application development suite; it's called "iDBIO" ("dbiogen" internally). For more details, call Bob Fultz at 415 438 2027; his netaddress is bfultz@indetech.com -- ____*_ Rick Cobb rcobb@indetech.com, \ / / Independence Technologies {sun,pacbell,sharkey}!indetech!rcobb \/ / 42705 Lawrence Place FAX: (US) 415 438 2034 \/ Fremont, CA 94538 Phone: (US) 415 438 2004
lrs@indetech.com (Lynn Slater x2048) (02/08/91)
Kermit> Has anybody come up with either a C++ base object for manipulating
Kermit> Oracle tables or a good C data/method hiding module source set. One of
Kermit> the problems with dealing with Pro*C and C++ is that each set thinks
Kermit> that it's the only preprocessor to Old C. Has anyone come up with a
Kermit> good set of makefile rules for dealing with this combination?
ITI has a program, fix-pcx, that takes Oracle Pro-C output and makes it
acceptable to C++, either gnu or a Cfront port. We also have makefiles and
otehr program development technques to support this and even to support
symbolic debugging despite the fact that Pro-C messes up the #lines offsets.
We have not sold this package as a separate item because it is not all that
big a deal, but I am sure I could persuade the folks here to make it
available for some nominal fee.
If you want a big deal, ask about iDBio (or DBIOGen), which writes a C++
object that corresponds to a DB entity with some number of access
techniques (queries) and provides programmer protection while hiding the
use or Pro-C.
This package provides select (single or multiple), insert, update, and
delete on an entity based on one of its access techniques (where clauses)
while insuring that all attributes referenced by the where clause have been
set, that no changed attributes will be overwritten by a select, that no
update really goes to the db if no attribute changed (changing "Joe" to
"Joe" is not a change), that no insert happens if any attribute is not set
or has not been set since the last change in the key attributes, etc.
The generated classes also give you C++ COMPILE TIME check on the
correctness of your types and their correspondence to the entity
definition. For example, with iDBIO, it is trivial to insure that no one,
no matter how unfamilar with the base schema or its design, adds an area
code to a credit balance and stores it as an employee number.
Special support is present for Oracle date and soundex capabilities.
--
===============================================================
Lynn Slater -- lrs@indetech.com or {sun, ames, pacbell}!indetech!lrs
42075 Lawrence Place, Fremont Ca 94538
Office (415) 438-2048; Home (415) 793-1864; Fax (415) 438-2034