Re: Finding a record in a TADOTable

There is no such thing as processing that is too complicated for a stored
procedure.

"Edward Diener" <eddielee_no_spam_here@xxxxxxxxxxxxxx> wrote in message
news:4294a5bf$1@xxxxxxxxxxxxxxxxxxxxxxxxx
> Kevin Frevert wrote:
> > "Edward Diener" <eddielee_no_spam_here@xxxxxxxxxxxxxx> wrote in message
> > news:429497e9$1@xxxxxxxxxxxxxxxxxxxxxxxxx
> >
> >>Easier, it seems, is to read all 100000 records
> >>into an ADOTable at one time and then see what I have to do.
> >>
> >
> >
> > There aren't many situations where sending 100,000+ records down that
little
> > wire is necessary. As your finding out, using table-based components
> > against a set-based RDBMS has a number of issues. Using the right tool
for
> > the job will solve a number of future issues (ex. in a multi-user
> > environment).
> >
> >
> >>I am aware of client-server programming, and I am aware that using
> >>queries is often better than using tables, but when one has to deal with
> >>random data that needs to be processed it seems that using a table may
> >>sometimes be better. However I am willing to listen to all sides.
> >
> >
> > In situations where you need to process that many records, I recommend
using
> > stored procedures. Let the server, not your Delphi code, do the work.
>
> I can send each record to a stored procedure and let it determine
> whether the record should be inserted or updated, based on whether there
> is a record which already exists with the given key. But the rest of the
> processing to determine which records should be chosen for the update
> set is quite complicated and can not be done by a stored procedure.
> Thanks for your suggestion and I will look into stored procedures as a
> means of making a one time trip of data from the client to the server.


.