Re: Oracle DB via Access - Still C/S?

On Fri, 14 Feb 2003 18:12:42 -0500, "Jason W. Paul" <nobody_at_nowhere.com> wrote:

>
>"Steve Jorgensen" <nospam_at_nospam.nospam> wrote in message
>news:rrqq4vkntcimrsuidvija6v3mcdjd0dd96_at_4ax.com...
>> On Fri, 14 Feb 2003 18:09:02 -0330, Tim Marshall <Sabot_at_Spam.On>
>> wrote:
>>
>> >Crossposted to comp.databases.ms-access and comp.databases.oracle.tools
>> >
>> >I do plenty of apps with Access as the application and Oracle as the
>> >database using ODBC and Access SQL against linked Oracle tables as well
>> >as Access pass through queries (using Oracle SQL against the ODBC DSN).
>> >
>> >Is such an arrangement still considered to be a client server
>> >application? This question may belie my uncertainty about the exact
>> >definitions of a client server application (what I believe most of the
>> >Omnis/Oracle, Powerbuilder/Oracle I am familiar with are) versus a file
>> >server app.
>> >
>> >Thanks in advance for any comments on this subject. I apologise for the
>> >cross post, but felt the question was relevant to both groups.
>>
>> The conventional definition of C/S with regard to database
>> applications refers to the fact that there is a database server
>> process running on the request of a client application. Oracle
>> vertainly is a database server! Therefore, using Access as a
>> ffront-end to Oracle is unquestionably C/S.
>
>I disagree. In a lot (lot more than I care to accept) of situations, if
>you're using linked tables, the brain-dead Jet engine decides that
>the server shouldn't do any processing and will drag *huge* amounts
>of data, kicking and screaming (to the chagrin of your network folks
>and DBA) across the wire -- essentially negating the entire C/S model.
>
>If all data access is done via pass-thrus, then yeah, I'd say it's C/S.
>
>If you've got a lot of linkage (linked tables) going on then, maybe
>it's C/S maybe not -- depending on what Jet decides to do with the
>queries
>
>Just wait 'til you're hitting a big table with a couple of 100s of
>millions of records and Jet decides to go flakey. It will. Randomly.
>Most times it will be very smart about data access but sometimes it
>will change the query plan and do something stupid -- totally brain
>dead. If you've got millions of rows, and it decides to get stupid on
>ya, you're screwed.
>
>Because of this, you'll want most (if not all) of your data access
>to be via pass-thrus, and even those should not contain any "raw"
>SQL, but should be calls into pre-compiled stored procs on the
>DB server. In the "old days" I switched to ODBCDirect for this
>kind of stuff, guaranteeing that Jet would be bypassed.

1. If an app is written badly and negates much of the benefit of the C/S model, it's still the C/S model.
2. Access queries properly forward logic to the back-end in most cases, and the rules for when it can't are very clear and logical. In some cases (not most in my experience), stored procedures need to be empoyed. Views are also a big help without nearly the coding hassle of SPs.

>I actually skip pass-thru querydef objects completely and now
>do all data access via ADO in code.

Well, many would argue that what you describe is the only right way to write a C/S app because the business rules should be implemented on the server so as not to be dependent on a single particular front-end. For single front-end apps, though, I've found Access queries to be great in 90% of use cases. Some tweaking is sometimes required to make it work properly, but then you've got a front-end that's easily portable to different brands of server because the dependency on back-end code is very limited. Received on Sat Feb 15 2003 - 00:34:43 CET