Re: Opinions on approach, please...

On Tue, 27 May 2008 12:09:20 +1200, "Pete Dashwood" <dashwood@xxxxxxxxxxxxxxxxxxxxxxxxx>
wrote:

"Frederico Fonseca" <real-email-in-msg-spam@xxxxxxxxx> wrote in message
news:8d9m34h0rhsnnb00r0c9t6mkv7eh3pbltk@xxxxxxxxxx
On Sun, 25 May 2008 14:41:09 +1200, "Pete Dashwood"
<dashwood@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote:

I'd like to get some other opinions on the stickier bits... :-)

Obviously START is problematic because it has a condition attached to it.
I
can parse this condition and translate it into an SQL condition to go into
a
WHERE clause, but I'm not sure whether it might be better to do this with
dynamic (PREPAREd) SQL (I could almost pick up the COBOL condition
verbatim)
or to use a static definition for each of the possible relational
conditions. Any thoughts?
As I said on another post, it is hard to give a accurate response
without know EXACTLY how this application works.


Yes, I know... :-)

I am looking for a general solution; it cannot be specific.

Specific is cheaper. The client doesn't need a tool that will convert every Cobol program
ever written, he wants you to convert one system.

Another price of general solutions is slow execution because they're interpretive. The
user pays a little every time he runs a transaction.

But it has a adverse effect.

While my second example will use 4 columns to access the index and
determine which records to retrieve, the 3rd one will only use the
first 3, even though product_code will be a sargable predicate. This
obviously depends on the database engine you use, and whether the SQL
is bound at runtime or at compile time, and if at compile time,
whether variables are optimized at runtime or not. (rmdb dependent).

MOST will be late bound. I never use early binding. Besides, it will be a
COM component and late binding is much better in that environment.

Frederico is referring to when the SQL is bound (compiled), not your program.

I think you get the general idea here. Main thing is to identify
,first of all, what are the possible START conditions for each current
index on each indexed file.

Can't do that.

Once this is done, you will have a good idea of how many cursors you
will need PER index. It may be the case that you will need to create
more than 1 per index in order to keep performance acceptable (and
don't tell me you are not considering it at the moment. You will
regret it if you do not).

It is a passing consideration at the moment, down a number of other
priorities. (Get the system to work with RDB as a data source would be the
top priority... :-))

In that case, you want IBM's COBOL Direct Connect and Micro Focus. You don't have to
change the source code at all.


.

Relevant Pages

  • Re: Opinions on approach, please...
    ... can parse this condition and translate it into an SQL condition to go ... dynamic SQL (I could almost pick up the COBOL condition ... is bound at runtime or at compile time, and if at compile time, ... you want IBM's COBOL Direct Connect and Micro Focus. ...
    (comp.lang.cobol)
  • Data Access Software Architecture?
    ... applicaitons that are heavy on database manipulation. ... related tables and has its own set of stored procedures. ... would have compile time checking of your SQL. ... I sometimes find not being able to see SQL in my code a little ...
    (microsoft.public.dotnet.framework)
  • Data Access Architecture w/ OOP
    ... applicaitons that are heavy on database manipulation. ... related tables and has its own set of stored procedures. ... would have compile time checking of your SQL. ... I sometimes find not being able to see SQL in my code a little ...
    (comp.object)
  • Data Access Layer Architecture?
    ... applicaitons that are heavy on database manipulation. ... related tables and has its own set of stored procedures. ... would have compile time checking of your SQL. ... I sometimes find not being able to see SQL in my code a little ...
    (comp.lang.java.programmer)
  • Re: Embedded SQL in C#
    ... like it has a lot of merit but there seems to be a substantial up-front ... Embedded SQL can be verified at compile-time. ... column name, invalid table name, or SQL syntax error. ... PowerBuilder provides an option to report SQL errors at compile time. ...
    (microsoft.public.dotnet.languages.csharp)