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: Better "Join" vs "Where" clause?
    ... running the SQL directly, in the SQL Server tools, rather than ... WHERE clause has been deprecated, ... AFAIK one cannot perform an outer join in Access without using the explicit ...
    (microsoft.public.access.queries)
  • 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: Performance degradation with view and "left outer join" vs. "from x, outer y"
    ... Turned Every Which Way But Loose", I reminded the attendees that the ANSI SQL '92 parsing rules REQUIRE that filters in the WHERE clause of a query MUST be processed POST-JOIN in order for an RDBMS to be compliant. ... That means that your filter, c.custid = "AB1234", is applied after all rows of the customer table have been LEFT OUTER JOINed to the my_view VIEW with the results stored into a temp table. ... Now if I use the informix extended outer join syntax: ...
    (comp.databases.informix)
  • 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)