We implement our SQL queries in our applications using embedded SQL/C
and the esqlc precompiler. We now have serious performance problems on
the client side.
Our Setup is the following (but we have similar Problems using other
setups):

Server: Win XP Pro, Ingres II, 2.6, DBMS, Net
Client: Win XP Pro, Ingres II, 2.6, Net Client

Responses to queries issued from the client are 7 times (and even
more) slower than the same query issued on the server. The load on the
server ist minimal: no one else than the client has access to it,
because it's a test environment.

We analysed the program execution using a profiler. It reports that
the most time on the client is consumed by a function called GCsync()
in OICLFNT.DLL.

The tmdemo test program from the Ingres SDK shows the same effect.

We also mesured the query answer time using II_EMBED_SET (set
II_EMBED_SET=printqry;qryfile c:\temp\output.txt) while issuing the
same queries on client and server. As far as we can see, the time
difference between a server and client query is negligible, but I'm
not sure if our interpretation of the output is correct (does anybody
knows more details about the correct interpretation of this output?)
Example:
Query text:
execute query (myquery115) 1 255 5400 5599
Query Send Time: Thu Jul 29 13:21:43 2004
Query Response Time: Thu Jul 29 13:21:43 2004
Response CPU Time: 500
Qry End CPU Time: 500

So the key questions are:
- Is anybody out there who has similar problems?
- How can these problems be solved?

Thank you!

Christopher

"Christopher" <ch.borbach (AT) axes-systems (DOT) com> wrote

How many rows are you getting back? I immediately suspect row-at-a-time
transfer over a busy network.

This trace is generated at the client end of the query. In the case of a
query from a workstation it shows the time the query was sent to the server,
and the time the server finished sending results back, across the network.
In the case of a client running on the same machine that also hosts the
server, it shows the same information except there would be no "wire
network" delays.

These things crop up all the time. I don't know anyone who doesn't have
them.

In innumerable ways. You'll need to provide lots more background
information. We'd need to see the SQL (with actual criteria), the table
definitions, and a trace done when there was a problem. (I'm not clear if
you are asserting the one above was done when a problem occurred, or not.)
If the one above shows what happened when you had a slow response then I'd
say it's not an Ingres problem.

If the above was not a slow query, then looking at the BIO count before and
after running a slow query might be instructive. (Use select
dbmsinfo('_bio_cnt').)

Roy Hann (rhann at rationalcommerce dot com)
Rational Commerce Ltd.
www.rationalcommerce.com
"Ingres development, tuning, and training experts"

hi im missing this file

OICLFNT.DLL


how can i get it?


--
obstruction

On Mar 27, 5:29*am, Ingres Forums <info-
ing... (AT) kettleriverconsulting (DOT) com> wrote:
That is some powerful zombie powder, to revive a post from Aug 12
2004 ;-)

OICLFNT.DLL is a dll from the old (and closed source) version of
Ingres. If you really need it you would have a support contract for
the older version. I would log an issue with Ingres support they can
help id what you need (and _maybe_ dig out the old binaries).

You may be better off rebuilding the application with a recent
version.

Chris