Re: Can I append an ADO recordset to an Access table in one go?



Many thanks to all contributors. Facinating stuff but I'm affraid not
terribly helpful as a practical way forward to my question. I am interested
in the batch update XML suggestion but this is new ground for me. Do you
have any examples? I don't mind about 'best practice' - I just want a
solution thant works. Sorry to be blunt.

"Stephen Howe" wrote:

The reason for my negativity is the tendency to discount/reject very
powerful techniques, that most definitely do have constructive uses,
merely because they've been designated "not best". The OP asks, "is there
a way...?" The answer is yes, but only by changing the construction of
the recordset to suit your needs, which is very much possible to do, in
its persisted form.

I'm sure MS' motivation to discourage developers from foraging into this
realm involve the difficulty in supporting those who attempt to undertake
it without sufficiently considering all the ramifications -- all part of a
trend towards making thing's "easier" at the expense of exposing truly
powerful constructs. Does that mean capable developers should sacrifice
functionality in favor of "best practice"? IMHO, the answer is not just
no, but hell no.

There are some of us for whom that "ease > power" mindset is a hinderance,
not a help. For example (not that it strictly pertains here, but just to
describe my mindset) I consider the premise of Windows API being called
deprecated to be obscene and insulting. It logically follows that I have
great difficulty accepting, "oh don't do that, it's not best, just be
happy with what they gave you."

In the case of this OP, it's the classic "what you want is likely not what
you need" scenario, so I pointed that out. The reason what he wanted to
do is likely not the best choice is that other options may be better
suited. But there have been times that my suggestions were contradicted
for the sole reason "not a best practice" and if you hadn't already
guessed, that rubs me the wrong way. So I thought I'd try to preempt
that.

Apologies if you objected to the "Microsoft-annointed flock" reference, it
was aimed at Microsoft MVP as an institution, not you specifically. If
you'd care to suggest an alternate term that does not infer undue esteem,
I'll consider using it in the future.

-Mark

I essentially agree with you for different reasons.
I agree with "Best Practice" on the whole but you have to take into account
that different programmers may have "constraints" that they are operating
under.
Those "constraints" may mean that instead of 1 Best Practice solution, you
have a variety of Best Practice solutions and you choose the best that
_ALSO_ fits the "constraints" you are operating under.
After all, for opening a Recordset, we have a choice of options:
server-sided versus client-sided, all the different cursor types, all the
different lock types.
There is not 1 way of opening a Recordset, there are many and the best
depends on the "constraints" the programmer is operating under.

For copying data from one server to another, DTS has often been advised.
But it may be that programmatic solution is required.
If that is the case, 2 programmatic solutions are possible:
(i) Getting one server to recognise the other and then doing an SQL
INSERT INTO table SELECT flds FROM remotetable
(ii) Using recordsets at last resort

It is the same with, say, sorting data.
Pretty much the case, a hybrid quicksort is the fastest general purpose
comparison s