Fox - using native dml on native data is monolithic. It is neither good or bad - it just is.....

I think the think that kicked this off was your assertion that you could write a "more sophisticated" app in Fox using native data and dml than I could using Fox + MSDE. My only point was that monolithic - given the current state of the art - cannot be considered more sophisticated than an n-tier solution. Again, that is not to say that monolithic is bad - its just not as sophisticated as other approaches.

HTH...

< JVP >


>>If you are using native data, ddl, dml - it is monolithic.
>
>Is that "your" definition of "monolithic", or can you refer me to another source ? Is that a local context only, or does it also include distributed processing ? If processes are running local, but in different address spaces, are they still monolithic ? Is a local app and local MSDE monolothic ? If I move the MSDE to a remote machine, am I now "non-monolithic" ? If I create "remote" services or objects that uses native data, ddl, dml ... are they still monolithic ? ... or, are "they" monolithic, but the "app", as a whole (which includes "remote" consumers), is not ? Can an app be both monolithic and n-tier at the same time ? Or, are you saying, that as long as one is NOT using SQL Server (or Oracle, etc), "it is monolithic" ? Stored procedures use a "native" DML/DDL relative to the server's interpreter; are "stored procedures" therefore monolithic ? Or are they NOT monolithic because a client may be located on another "tier" ? What if the client and stored procedure are on the same
>tier ? If a stored procedure is not monolithic, and calls another stored procedure, is the called procedure still not monolithic ? Are "triggers" monolithic ? Triggers are "called" by the server, use "native" DML/DDL, and typically run on the same tier; therefor triggers must be monolithic ... No ? Is monolithic "bad" ? If triggers and stored procedures are monolithic, and monolithic is "bad" ...