Re: Dreaming About Redesigning SQL

A long time ago, in a galaxy far, far away, andrewst <member14183_at_dbforums.com> wrote:
> What you advocate is what we had no choice but to do years ago, before
> database-level constraints existed. You built a screen to enable input
> of orders, you had to encode ALL the data integrity rules in the screen
> code; you added a second screen to facilitate bulk-input of many orders,
> you had to duplicate all the data integrity rules; client/server came
> along, and you rewrote the application in a new tool, rewriting all the
> data integrity rules in the new client language. Hopefully by this
> point you could move the data integrity checking to the server, and
> hopefully you did. If not, when web-enabled became the vogue and you
> re-wrote your application in Java, you had to recode all the data
> integrity again...

.. And that is why the "proper" way of importing data into SAP R/3 does not involve loading it into the database, but rather requires that you write "BDC" programs, where you read data from the source, and populate simulated fields on simulated screens.

You populate _screen_ fields, indicating where virtual buttons need to be 'pressed' to go from screen to screen.

This 'compiles' into what is called a "BDC session," which is then run against an emulator that pretends to be a screen, and passes the data through that "screen validation code."

Quite recently, SAP has started providing "business functions" that provide a more "API-oriented" way of doing this because the BDC approach was _so_ excruciatingly painful to debug, and was so inefficient.

-- 
output = ("cbbrowne" "_at_" "cbbrowne.com")
http://www3.sympatico.ca/cbbrowne/x.html
MICROS~1:  Where do you  want to  go today?   Linux: Been  there, done
that.