database connection to oracle

[antonberg1]

Hi,

I wonder if it is possible to write a platform independent
c-application running as job on a sun solaris multiprocessor machine,
connecting to an oracle database and creating a very simple xml-file
from the data extracted.

Could you maybe give me some advice where to start reading about that
theme? Usually I develope windows applications, but this time my
software has to run on sun solaris.

Btw. it would be perfect, if there are some database librarys
available, which are more or less platform independent, so that I can
develop my application on my windows workstation and (maybe after some
simple changes) let run it later on the solaris server.

In fact, I think there should be a solution for this problem, cause my
application is very simple:
1.) Read in data from database
2.) Do some minimal changes to the database
3.) write the xml-files

Do you know of any emulator for sun solaris on windows?

Thanks for all your help,
Anton

[Vladimir S. Oka]

an********@gmx.de wrote:

Hi,

I wonder if it is possible to write a platform independent
c-application running as job on a sun solaris multiprocessor machine,
connecting to an oracle database and creating a very simple xml-file
from the data extracted.
That depends on whether you plan to use any fancy multiprocessor or
*nix specific features. If you answer yes to this question, answer to
yours is no, but see below.
;-)

Could you maybe give me some advice where to start reading about that
theme? Usually I develope windows applications, but this time my
software has to run on sun solaris.

Btw. it would be perfect, if there are some database librarys
available, which are more or less platform independent, so that I can
develop my application on my windows workstation and (maybe after some
simple changes) let run it later on the solaris server.

In fact, I think there should be a solution for this problem, cause my
application is very simple:
1.) Read in data from database
2.) Do some minimal changes to the database
3.) write the xml-files
If you really only want to run your app, and do 1-2-3 as above, it
seems perfectly possible to write something platform-independent. It
won't be database-format independent, but that probably hardly matters.
It wouldn't even require too much reading, apart from the Oracle
database format spec.

Do you know of any emulator for sun solaris on windows?
Sun has recently open-sourced Solaris, so have a look at:

http://www.opensolaris.org/

and you can probably install it on your own machine.

Thanks for all your help,

I know it probably wasn't much help, but hey, it's a slow day at work.
;-)

Cheers

Vladimir

[antonberg1]

Hi,

what do you mean with fancy multiprocessor? Will this help me to speed
my application up?

Currently this step is performed by a perl script and it needs about
1:40h to finish the total process (finally we get 1,5GB of XML-Files...
8 files as I remember correctly). My idea was now to speed the process
up in using C... Do you think this will help?

Thanks for your suggestions.
Anton

[Flash Gordon]

an********@gmx.de wrote:

Hi,

I wonder if it is possible to write a platform independent
c-application running as job on a sun solaris multiprocessor machine,
connecting to an oracle database and creating a very simple xml-file
from the data extracted.
No. You will need some non-standard libraries and might fins others to
be useful.
Could you maybe give me some advice where to start reading about that
theme? Usually I develope windows applications, but this time my
software has to run on sun solaris.

Btw. it would be perfect, if there are some database librarys
available, which are more or less platform independent, so that I can
develop my application on my windows workstation and (maybe after some
simple changes) let run it later on the solaris server.
There are various libraries available for talking to databases, however
as they are not standard C say are not topical here. Ask on groups
dedicated to the implementations of interest or the databases of interest.
In fact, I think there should be a solution for this problem, cause my
application is very simple:
1.) Read in data from database
2.) Do some minimal changes to the database
The first two require non-standard libraries.
3.) write the xml-files
This can be done in standard C, however you may also want to look at
non-standard libraries such as libxml that can assist in this.
Do you know of any emulator for sun solaris on windows?

This last part has absolutely nothing to do with C. Try asking on
Windows and/or solaris groups.
--
Flash Gordon
Living in interesting times.
Although my email address says spam, it is real and I read it.

[Vladimir S. Oka]

[e-mail] wrote:

Hi,
Please quote what you're replying to, otherwise many people won't know
what you're on about... If you're using Google follow the advice at the
bottom.
what do you mean with fancy multiprocessor? Will this help me to speed
my application up?
You mentioned "multiprocessor" as if it had to do something with your
design. I don't know about multiprocessors, neither does the C
standard. Don't get me wrong, I honestly don't know, and it's honestly
not topical here, but I'm sure if you could utilise it it'll speed up
your app -- at the expense of portability. ;-)

Currently this step is performed by a perl script and it needs about
1:40h to finish the total process (finally we get 1,5GB of XML-Files...
8 files as I remember correctly). My idea was now to speed the process
up in using C... Do you think this will help?

Re-writing the Perl app in C, which is compiled rather than
interpreted, is almost certain to speed things up in itself, but YMMV
depending on many factors, C skill included. This is probably the
easiest way to do it. Note that you may trying to climb a steep hill if
your app relies heavily on Perl language/library features that don't
exist in C, and will hence need to be "re-invented" by you unless you
can find a good existing (free?) implementation. I'm not familiar with
Perl, so I won't even try to double guess these.

Cheers

Vladimir

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
More details at: <http://cfaj.freeshell.org/google/>

[Keith Thompson]

"Vladimir S. Oka" <no****@btopenworld.com> writes:

an********@gmx.de wrote:

[...]

In fact, I think there should be a solution for this problem, cause my
application is very simple:
1.) Read in data from database
2.) Do some minimal changes to the database
3.) write the xml-files

If you really only want to run your app, and do 1-2-3 as above, it
seems perfectly possible to write something platform-independent. It
won't be database-format independent, but that probably hardly matters.
It wouldn't even require too much reading, apart from the Oracle
database format spec.

I'm not familiar with Oracle, or with databases in general, but it
seems unlikely that depending on the disk format of the database files
would be a good idea. Using Oracle's defined *interface* to the
database (SQL or something?) is likely to be cleaner, easier, and much
more robust.

There are several newsgroups with "oracle" in their names.
rec.humor.oracle is likely to be more amusing than useful, but you
should check out the others.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Mark McIntyre]

On 24 Jan 2006 07:00:38 -0800, in comp.lang.c , an********@gmx.de
wrote:

I wonder if it is possible to write a platform independent
c-application running as job on a sun solaris multiprocessor machine,
connecting to an oracle database and creating a very simple xml-file
from the data extracted.
Not without a lot of work, since you would at the very least need some
sort of oracle connectivity layer. Obvoiusly you could write your own
oracle client interface, and port that to each platform you intended
to support. Ouch.
Could you maybe give me some advice where to start reading about that
theme? Usually I develope windows applications, but this time my
software has to run on sun solaris.
Solaris is no different to windows. A C app has a main() and you can
link with libraries just the same. Just don't use windows system calls
in your C.
Btw. it would be perfect, if there are some database librarys
available, which are more or less platform independent, so that I can
develop my application on my windows workstation and (maybe after some
simple changes) let run it later on the solaris server.

Oracle client does this, its why Oracle wrote it.... :-)
Mark McIntyre
--
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----

[Mark McIntyre]

On Tue, 24 Jan 2006 17:38:36 GMT, in comp.lang.c , Keith Thompson
<ks***@mib.org> wrote:

I'm not familiar with Oracle, or with databases in general, but it
seems unlikely that depending on the disk format of the database files
would be a good idea.
Quite a few real DB vendors require you to format the disk using their
own filesystem, and accessing it conventionally is pretty much
impossible.
Using Oracle's defined *interface* to the
database (SQL or something?) is likely to be cleaner, easier, and much
more robust.

Yup.
Mark McIntyre
--
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----

[Jordan Abel]

On 2006-01-24, Keith Thompson <ks***@mib.org> wrote:

"Vladimir S. Oka" <no****@btopenworld.com> writes:

an********@gmx.de wrote:

[...]

In fact, I think there should be a solution for this problem, cause my
application is very simple:
1.) Read in data from database
2.) Do some minimal changes to the database
3.) write the xml-files

If you really only want to run your app, and do 1-2-3 as above, it
seems perfectly possible to write something platform-independent. It
won't be database-format independent, but that probably hardly matters.
It wouldn't even require too much reading, apart from the Oracle
database format spec.

I'm not familiar with Oracle, or with databases in general, but it
seems unlikely that depending on the disk format of the database files
would be a good idea. Using Oracle's defined *interface* to the
database (SQL or something?) is likely to be cleaner, easier, and much
more robust.

There are several newsgroups with "oracle" in their names.
rec.humor.oracle is likely to be more amusing than useful, but you
should check out the others.

Yes, such as rec.humor.oracle.d

[Keith Thompson]

Jordan Abel <ra*******@gmail.com> writes:

On 2006-01-24, Keith Thompson <ks***@mib.org> wrote:

[...]

There are several newsgroups with "oracle" in their names.
rec.humor.oracle is likely to be more amusing than useful, but you
should check out the others.

Yes, such as rec.humor.oracle.d

And people think *I'm* picky! 8-)}

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Anton Berg]

Hi,

Mark McIntyre wrote:

Not without a lot of work, since you would at the very least need some
sort of oracle connectivity layer. Obvoiusly you could write your own
oracle client interface, and port that to each platform you intended
to support. Ouch.

Ok, so probably, that's not such a good idea.

Btw. it would be perfect, if there are some database librarys
available, which are more or less platform independent, so that I can
develop my application on my windows workstation and (maybe after some
simple changes) let run it later on the solaris server.

Oracle client does this, its why Oracle wrote it.... :-)

Do you think there will be a speed advantage in using C instead of Perl?
Will this give me anything, or is Perl quite a good choice for this kind
of work? Currently the Perl job needs 1:40h to generate ca. 1,5GB of xml
files (8 different files).
The Perl script does:
1. Read the data from the database (8 simple select statements).
2. Does some changes to the data, e.g. changes the german character ä to
ae and other things like that.
3. Generates the XML files.

What do you think?

Thanks for your help!
Anton

[Jordan Abel]

On 2006-01-25, Keith Thompson <ks***@mib.org> wrote:

Jordan Abel <ra*******@gmail.com> writes:

On 2006-01-24, Keith Thompson <ks***@mib.org> wrote:

[...]

There are several newsgroups with "oracle" in their names.
rec.humor.oracle is likely to be more amusing than useful, but you
should check out the others.

Yes, such as rec.humor.oracle.d

And people think *I'm* picky! 8-)}

actually, i thought it would be a great prank [on whom, i haven't yet
figured out] to send someone to RHOD asking about oracle.

[Joe Wright]

Mark McIntyre wrote:

On Tue, 24 Jan 2006 17:38:36 GMT, in comp.lang.c , Keith Thompson
<ks***@mib.org> wrote:

I'm not familiar with Oracle, or with databases in general, but it
seems unlikely that depending on the disk format of the database files
would be a good idea.

Quite a few real DB vendors require you to format the disk using their
own filesystem, and accessing it conventionally is pretty much
impossible.

Using Oracle's defined *interface* to the
database (SQL or something?) is likely to be cleaner, easier, and much
more robust.

Yup.
Mark McIntyre

You definitely have to peel the onion.

The DBMS (Oracle, Informix, etc.) will get you inside the playpen. Once
inside, it is the application that rules, not the DBMS.

You will want help from the application vendor about API's and other
tools to make sense out of all that data that you are now in the middle
of. Being able to read a table with SQL tools is nice but does not solve
the problem.

You need to know what the database represents and how the various tables
are related. Data Dictionaries and Entity Relationship Diagrams are your
friends.

As I get into this post, it's beginning to seem OT. Sorry.

--
Joe Wright
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---

[Stan Milam]

Anton Berg wrote:

Hi,

Mark McIntyre wrote:

Not without a lot of work, since you would at the very least need some
sort of oracle connectivity layer. Obvoiusly you could write your own
oracle client interface, and port that to each platform you intended
to support. Ouch.

Ok, so probably, that's not such a good idea.

Btw. it would be perfect, if there are some database librarys
available, which are more or less platform independent, so that I can
develop my application on my windows workstation and (maybe after some
simple changes) let run it later on the solaris server.

Oracle client does this, its why Oracle wrote it.... :-)

Do you think there will be a speed advantage in using C instead of Perl?
Will this give me anything, or is Perl quite a good choice for this kind
of work? Currently the Perl job needs 1:40h to generate ca. 1,5GB of xml
files (8 different files).
The Perl script does:
1. Read the data from the database (8 simple select statements).
2. Does some changes to the data, e.g. changes the german character ä to
ae and other things like that.
3. Generates the XML files.

What do you think?

Thanks for your help!
Anton

It reads like you are a Perl bigot.
Regards,
Stan Milam.

[Nick Keighley]

Stan Milam wrote:

Anton Berg wrote:

Mark McIntyre wrote:
<snip>
Do you think there will be a speed advantage in using C instead of Perl?
Will this give me anything, or is Perl quite a good choice for this kind
of work? Currently the Perl job needs 1:40h to generate ca. 1,5GB of xml
files (8 different files).
The Perl script does:
1. Read the data from the database (8 simple select statements).
2. Does some changes to the data, e.g. changes the german character äto
ae and other things like that.
3. Generates the XML files.

What do you think?

It reads like you are a Perl bigot.

what?!! The guy asked if switching from Perl to C would be likely to
speed
up his application. And this makes him a Perl bigot? Methinks the
footware
is on an alternate limb...

[disclaimer: I do not program in Perl, I have never programmed in Perl.
I
would not recognise Perl if it was put in front of me]
--
Nick Keighley

[Ingo Menger]

Vladimir S. Oka schrieb:

[e-mail] wrote:

Currently this step is performed by a perl script and it needs about
1:40h to finish the total process (finally we get 1,5GB of XML-Files...
8 files as I remember correctly). My idea was now to speed the process
up in using C... Do you think this will help?

Re-writing the Perl app in C, which is compiled rather than
interpreted, is almost certain to speed things up in itself, but YMMV
depending on many factors, C skill included.

This is very doubtful, especially if the run time is mostly database
and/or i/o-bound.
It may well be that optimizing the database layout, database queries,
etc. would gain really something.
A C program that merely submits a SQL query, reads the result set an
then writes some data to files will hardly be faster than a perl
program that does the same. Unless, of course, the creation of the XML
from the database result involves CPU intensive computations.

[Flash Gordon]

Ingo Menger wrote:

Vladimir S. Oka schrieb:

[e-mail] wrote:

Currently this step is performed by a perl script and it needs about
1:40h to finish the total process (finally we get 1,5GB of XML-Files...
8 files as I remember correctly). My idea was now to speed the process
up in using C... Do you think this will help?

Re-writing the Perl app in C, which is compiled rather than
interpreted, is almost certain to speed things up in itself, but YMMV
depending on many factors, C skill included.

This is very doubtful, especially if the run time is mostly database
and/or i/o-bound.
It may well be that optimizing the database layout, database queries,
etc. would gain really something.
A C program that merely submits a SQL query, reads the result set an
then writes some data to files will hardly be faster than a perl
program that does the same. Unless, of course, the creation of the XML
from the database result involves CPU intensive computations.

Basically, the boils down to the old adage of measure before you do
anything. It could be that the Perl interface to the DB is inefficient,
the method of generating the XML is inefficient, it is spending all it's
time waiting for the DB, or for disk IO. Without measuring you will
never know.

A sufficiently well written C program won't be slower than a Perl
program, since the Perl interpreter is written in C, but whether the
effort required to produce a sufficiently well written C program is
justified is another matter. Note that it is also possible (and maybe in
some instances easier) to write a C program that will not perform as
well as a simple Perl program.
--
Flash Gordon
Living in interesting times.
Although my email address says spam, it is real and I read it.

[Vladimir S. Oka]

Flash Gordon wrote:

Ingo Menger wrote:

Vladimir S. Oka schrieb:

[e-mail] wrote:

Currently this step is performed by a perl script and it needs
about 1:40h to finish the total process (finally we get 1,5GB of
XML-Files... 8 files as I remember correctly). My idea was now to
speed the process up in using C... Do you think this will help?
Re-writing the Perl app in C, which is compiled rather than
interpreted, is almost certain to speed things up in itself, but
YMMV depending on many factors, C skill included.
I also said this here:
This
is probably the easiest way to do it. Note that you may trying
to climb a steep hill if your app relies heavily on Perl
language/library features that don't exist in C, and will hence
need to be "re-invented" by you unless you can find a good
existing (free?) implementation. I'm not familiar with Perl,
so I won't even try to double guess these.

This is very doubtful, especially if the run time is mostly database
and/or i/o-bound.
It may well be that optimizing the database layout, database queries,
etc. would gain really something.
A C program that merely submits a SQL query, reads the result set an
then writes some data to files will hardly be faster than a perl
program that does the same. Unless, of course, the creation of the
XML from the database result involves CPU intensive computations.

Basically, the boils down to the old adage of measure before you do
anything. It could be that the Perl interface to the DB is
inefficient, the method of generating the XML is inefficient, it is
spending all it's time waiting for the DB, or for disk IO. Without
measuring you will never know.

A sufficiently well written C program won't be slower than a Perl
program, since the Perl interpreter is written in C, but whether the
effort required to produce a sufficiently well written C program is
justified is another matter. Note that it is also possible (and maybe
in some instances easier) to write a C program that will not perform
as well as a simple Perl program.

My point was mostly your last point, but it was snipped by Ingo. I have
re-instated it above...

Cheers

Vladimir

--
Remember, even if you win the rat race -- you're still a rat.

[Mark McIntyre]

On Wed, 25 Jan 2006 01:04:19 +0100, in comp.lang.c , Anton Berg
<no****@nospam.de> wrote:

(of replacing some perl with C, for accessing a database)

Do you think there will be a speed advantage in using C instead of Perl?

No idea but possibly. You'd have to benchmark it.

Mark McIntyre
--
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----

[Mark McIntyre]

On 25 Jan 2006 00:10:35 -0800, in comp.lang.c , "Nick Keighley"
<ni******************@hotmail.com> wrote:

[disclaimer: I do not program in Perl, I have never programmed in Perl.
I
would not recognise Perl if it was put in front of me]

The first line is often a giveaway :-)

#!/usr/bin/perl
print "hello, world";

Mark McIntyre
--
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----

[Michel Bardiaux]

Mark McIntyre wrote:

On 25 Jan 2006 00:10:35 -0800, in comp.lang.c , "Nick Keighley"
<ni******************@hotmail.com> wrote:

[disclaimer: I do not program in Perl, I have never programmed in Perl.
I
would not recognise Perl if it was put in front of me]

The first line is often a giveaway :-)

#!/usr/bin/perl
print "hello, world";

Mark McIntyre

This cant be a legal perl program: the use of at least 4 non-obvious
specials characters is mandated. Like in

print "hello" %$->#@"world";

Oh, and 1-liners are considered much superior to 2-liners.

:-)

--
Michel Bardiaux
R&D Director
T +32 [0] 2 790 29 41
F +32 [0] 2 790 29 02
E mailto:mb*******@mediaxim.be

Mediaxim NV/SA
Vorstlaan 191 Boulevard du Souverain
Brussel 1160 Bruxelles
http://www.mediaxim.com/