Re: ODBC limits

At 07:28 AM 9/27/2002, you wrote:
>I'm trying to get information of the limitations of ODBC drivers,
>specifically Oracle's and Microsoft's drivers for Oracle.
>Things like maximum no. of records they can fetch etc.

I don't believe there's any limitation in the number of records you can get through ODBC, other than the amount of memory on the client. I've seen apps create resultsets that were very close to the limits of their clients without anything crashing.

Note that there's at least one major problem using ODBC and Access. Access will always download the whole resultset to the client before starting to display it. When you're dealing with large data volumes, this is really unfortunate.

You'll probably also need to play with the prefetch count if you're using ODBC with large data volumes. I don't think Access requests particularly large data chunks with every network round-trip. Since the Net8 protocol ACK's each data chunk, this can be a significant burden.

If you're actually going to be pulling large chunks of data across the network, I would advise you to strongly consider writing the front-end. You're probably going to want to have the control necessary to optimize traffic across the wire, the way data is managed in memory, etc.

You're not likely to get Random error messages trying to do this. Access may crash when it can't allocate additional memoy, things may be slow, etc.

> As I know very
>little about ODBC (which might be reflected in the nature of my question) I
>hope I'm asking a sensible question. I'm asking as there are some
>developers here who are getting a variety of error messages when dealing
>with large volumes of data from 8.1.7 DB into MS-Access. I'm trying there
>to ascertain where the problem lies, i.e. is it the driver, MS-Access,
>combination of both of these, or it's Microsoft what do you expect!!!
>
>Any (non-flame) feedback to useful web sites, white papers etc would be
>appreciated.
>
>-------------------------
>Seán O' Neill
>Organon (Ireland) Ltd.
>[subscribed: digest mode]
>--------------------------------------------------------------------
>This message, including attached files, may contain confidential
>information and is intended only for the use by the individual
>and/or the entity to which it is addressed. Any unauthorized use,
>dissemination of, or copying of the information contained herein is
>not allowed and may lead to irreparable harm and damage for which
>you may be held liable. If you receive this message in error or if
>it is intended for someone else please notify the sender by
>returning this e-mail immediately and delete the message.
>--------------------------------------------------------------------
>--
>Please see the official ORACLE-L FAQ: http://www.orafaq.com
>--
>Author: O'Neill, Sean
> INET: Sean.ONeill_at_organon.ie
>
>Fat City Network Services -- 858-538-5051 http://www.fatcity.com
>San Diego, California -- Mailing list and web hosting services
>---------------------------------------------------------------------
>To REMOVE yourself from this mailing list, send an E-Mail message
>to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
>the message BODY, include a line containing: UNSUB ORACLE-L
>(or the name of mailing list you want to be removed from). You may
>also send the HELP command for other information (like subscribing).

Justin Cave
Distributed Database Consulting

-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.com
-- 
Author: Justin Cave
  INET: jcave_at_cableone.net

Fat City Network Services    -- 858-538-5051 http://www.fatcity.com
San Diego, California        -- Mailing list and web hosting services
---------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).