Re: Opinions on approach, please...



"Robert" <no@xxxxxx> wrote in message
news:5nvl34pdmegh0jld4fnl3t0e80phj5k5an@xxxxxxxxxx
On Tue, 27 May 2008 01:47:26 +1200, "Pete Dashwood"
<dashwood@xxxxxxxxxxxxxxxxxxxxxxxxx>
wrote:

I can detect which key field is being used, I can detect the relation, I
can
get the data for the condition, and I can probably handle up to 3
connected
conditions, but I still don't havea clear idea of how I'll get this into
MOST... :-)

Write the where clause manually, one time.

Do you mean in the Application?

I REALLY don't want to do that. As stated elsewhere, I don't want ANY SQL in
the applications at all. All I want to see there is an invocation of the
MOST interface, with the original COBOL ISAM access commented out above it.

It is important for future language migration to create a data access layer
that is not embedded in COBOL.

Obviously, I can't write specific accesses into MOST manually.

The real problem is how to process the data from the interface, regarding
the relation in the "condition" clause of the START statement, inside MOST.

I can certainly do it with dynamic SQL and MOST can build a WHERE statement
from the data in the interface, then add that to the cursor statement and
EXECUTE it. It will incur a performance hit, but I don't know how critical
that is likely to be. It really depends how much of their current
application is doing lengthy sequential processing, how often, in what
sequences, etc. I know they use READ NEXT quite a lot for building drop down
lists for their PowerCOBOL GUI, but these are typically fairly small
accesses incurred only when a form is loaded and driven from that event.

The other alternative is to have the process that scans the application code
for replacement with MOST invocations, statically build the WHERE clause and
insert it into the application, but I don't want to do that as it violates
my goal of having no SQL in the application. (Besides, I'd then need to put
consequent FETCHes on the cursor into the application as well, and that gets
ugly very quickly... :-))

When I fnally get to solve this (it should be by the end of this week), I'll
post the code here and let the pundits pick it over... :-)

Thanks for your post, Robert.

Pete.
--
"I used to write COBOL...now I can do anything."


.

Relevant Pages

  • Re: Application, database and schema?
    ... > hardware interface for the monitoring. ... This subsystem understands how to talk to the ... > this case an RDB with a SQL interface. ...
    (comp.object)
  • Re: the "having" clause
    ... Start in the FROM clause and build a working table from all of the ... rest of the containing query. ... e) Go to the SELECT clause and construct the expressions in the list. ... As you can see, things happen "all at once" in SQL, not from left to ...
    (microsoft.public.sqlserver.programming)
  • Re: Report Parameters - no results
    ... Allen Browne - Microsoft MVP. ... I did use the WHERE clause you suggested, and now I'm getting the "wrong ... > What else can I do to try to correct my sql? ... >> the WHERE clause in your query. ...
    (microsoft.public.access.reports)
  • RE: open a text file using sp_oamethod
    ... sp_OAGetProperty Fails on Properties From Inherited Interface ... Source: ODSOLE Extended Procedure ... When no OUTPUT parameter is supplied, ... Microsoft has confirmed this to be a problem in SQL Server 7.0. ...
    (microsoft.public.sqlserver.programming)
  • =?iso-8859-1?Q?Re:_Abfrage_meherer_MWSt.-S=E4tze?=
    ... der bereits Rechnungen mit x ) Positionen und mehreren Mehrwertsteuersätzen sinnvoll zu gruppieren und zu summieren hatte? ... Obwohl die Hilfe mindestens 70 Einträge zum Thema SQL aufweist, oft mehrere Seiten je Thema bzw. je Befehl mit Querverweisen und auch mit Beispielen geschmückt ist. ...
    (microsoft.public.de.sqlserver)