About Contracters
News
Vacant positions
Contact Contracters
Sitemap
Current News News Archive Newsletters

Home


Newsletters
(August, 1999)

  1. 5 years of total fulfilment
  2. Considerations before integrating Oracle and MS-Office
  3. Using C/C++ with Oracle Desiger

5 years of total fulfilment Tilbage

123


Can you look back on your career in the computer field and say ‘that was a super job’?


I am not talking about a 3 month or even a 1 year period. I am one of the few lucky ones who had a ‘super job’ which spanned a 5 year period of my 32 years as a computer professional.


Back In 1967


Just to give you a bit of background. I got into commercial computing as a trainee programmer back in the computing dark ages of 1967. In those days it was just called plain‘EDP’ (electronic data processing).


The computer was a state of the art Honeywell 200, with 5 tape units, no disk, paper tape input and a gigantic 20K cpu. Yes and we wrote Cobol programs which were smaller than 20K!!!


From the start of my career I was very end-user oriented, getting uppermost satisfaction in seeing the end-users using what I had produced for them.


10 years and several jobs and one country later, I had achieved my goal and was head of a computer department, this being at the Swiss Lottery. Now the ladder had seemed to run out of rungs. After nearly 4 years in this position, I felt like a change. But what?


New Challenge


My next job took me to one of the Swiss Chemical/Pharmaceutical giants. For 3 years I worked on a Management Information System. At the end of 1986, within the same company, I got the possibility for a job in the pharmaceutical marketing department. It was explained to me that there would be a fair amount of travelling involved and that I would have to go to Atlanta for a 2 month ‘on the job’ training. Before I had much more info about the job, I asked ‘where do I sign?‘!


The technical components of the project were totally unknown territory for me. Laptops (I had never touched a pc till then and had never seen a laptop), DEC microVax, Ingres databases, SQL. Quite a bit different from the Cobol/PL1/CICS/IMS environment I was used to. I also didn‘t have a clue about Pharma Marketing.


Basically the project was for the pharma representatives, who visited doctors,hospitals and pharmacies to promote the company’s products, so that they could report their visits electronically instead of on scraps of paper. They could enter the visit data
directly after the visit and then upload the data to microVax at headquarters over public telephone lines when they returned home or to the hotel.


So big deal you might say, tell me something new. But I would like to remind you that we are talking about 1987 not 1999.


Exciting Months In Atlanta


The company we were working with had developed the generative software. The client, in our case the group company, defined what the reps should be seeing on the laptop and what information they should enter. These screens were then defined and generated. The screen
layouts were then uploaded to the VAX, thereby defining the interface file structures. These structures were used for up- and downloading data from and to the reps.


We set up an Ingres information and reporting database. Group companies which already had a system for reps’ information on a mainframe computer could retain this system and transfer information to the reps laptops via the VAX. Of course this system would also receive information from the VAX.


The information downloaded from the mainframe would include updates to the reps’‘client’ database and also reports.


Next Steps


In Atlanta we had been generating the ‘guinea pig’ project for our UK subsidiary. So 2 weeks after returning from the US, I was off to the UK for 2 months, to work on the installation team. The laptop side had been thoroughly tested and also the up-
and downloading to the VAX, but only with limited data and only in the Atlanta environment. It is always different at the client‘s site, for example the security issue, but there were also several other


Considerations before integrating Oracle and MS-Office Tilbage

123


Business data is typically stored in Oracle, and the user wants to utilise data in MS-office; this is an everyday scenario. Maybe the user wants to use data as source for mail merging in Word, or maybe he needs to make further calculations on data in Excel.The needed integration between the two worlds can be achieved in 2 ways:


  • Word / Excel can be launched from an Oracle Developer application (Forms or Reports) and data can be transferred to MS-office using OLE2.

  • From Word or Excel data can be loaded into MS-office using ODBC. 


Coming To A Decision


Which solution should be chosen? The answer to this problem is not always easily found,but the following questions might throw light on the decision:


  1. Does the user see the task as an Office task or an Oracle task?

  2. When does the user need the integration? Is it working in Oracle or working in MS-office?

  3. Which resources does the firm have in-house? Is it an in-house development project at all?

  4. Is it ad hoc queries that the user wants to utilise in MS-office or is it standard procedures?

  5. As developer or decision-maker, do you believe that Microsoft will not change the objectmodel of Word/ Excel?


OLE2 vs. ODBC


I have tried to summarise the pros and cons in the following table (- meaning disadvantage, + meaning advantage):


OLE2ODBC
Database application task+-
Word/Exel task-+
Well defined single elements to be put in well defined positions+-
Tables/Rows of information-+
Only MS-Office resources in-house+
Vulnerability to changes in Object model in MS-Office-?
Transparancy of code-+
Easy understandable "code"-+
Requires installed ODBC-driver for Oracle+-
Requires installed runtime versions of Oracle Developer-+
Expected TCO-+


So OLE2 is the obvious answer if the user sees the task as: an Oracle task, when working in some Developer application, and somebody in the company knows both Oracle Developer and the MS-office objectmodel, and it is no


Using C/C++ with Oracle Desiger Tilbage

123

Over the years, I have had quite a few discussions with other developers concerning
whether or not C/C++ has a place in modern, Oracle-based system development and what its place might be. Indeed, the advent of technologies such as PL/SQL and external database procedures has definitely diminished the need of using C/C++ for general-purpose commercial system development. Albeit these advances in system development technologies,C/C++ are, from my experience at least, used as extensively today as it were in the past.

This means that being able to integrate C/C++ with the Oracle development environment becomes as important as with any other development tools. To alleviate this, this article will suggest some feasible ways of integrating C/C++ modules with Oracle Designer.
However, the reasoning behind choosing C/C++ for any particular purpose is not within the scope of this article and it does not discuss the merit of using C/C++ for any particular purpose.


Skill Separation


To most professional Oracle Developers today, is it a bedrock approach to use the Oracle Designer CASE tool as a central repository for storing information pertaining to their development projects, and use this information to generate program modules.
Surprisingly, it seems as if only a few have successfully integrated C/C++ modules with Oracle Designer.


The reason behind this could be that one developer may be well versed in C/C++,object-oriented algorithms and operating system details; another may be a proficient Oracle developer, highly skilled in developing complex SQL programs; a third a
knowledgeable systems analyst capable of modelling complex business processes and data structures. But to find developers that are equally skilled in all of these branches of system development are rare.


This means that one of the primary objectives of using Oracle Designer with C/C++ is to separate the skills required to complete a given task. The basic divider is to separate the C/C++ programming skill from the SQL programming skill.


The Mixed Approach


The approach most commonly seen today is a way that may be labelled the "mixed" approach: This traditional way of accessing an Oracle database using C/C++ is to embed SQL and PL/SQL statements directly within the C/C++ source program files. These source files are processed by the Oracle Pro*C pre-compiler that transforms the SQL in the source files to a form that is syntactically understandable for a native
C/C++ compiler. The output from the native compiler is linked to a number of libraries to form an executable program. Another way is to use the "Oracle Call Interface(OCI)". It eliminates the need for the pre-compilation step, but demands that the programmer supplies very detailed information about how Oracle should process SQL statements.


These approaches are very flexible as they allow a developer to combine the access to almost all Oracle features with access to just about any features that may exist in a particular environment.


The main drawbacks are that developers must have the combined skills of programming with C/C++ as well as skills programming using SQL or PL/SQL. furthermore, embedding SQL directly in C/C++ source files may lead to that these files must be manually changed every time a change is made to an Oracle object that these files access. Oracle Designer
contains only very rudimentary features for manipulating files containing embedded SQL or OCI.


A solution to these drawbacks provided by Oracle Corporation is the "C++ Object Layer Generator".


The C++ Object Layer Generator


This tool is an integrated part of Oracle Designer that allows a developer to access an Oracle database from a C++ application. The generator reads the Oracle Designer definition of tables, views, columns, etc. and creates a number of C++ classes th


Return to Newsletters



© Copyright 1999 Contracters