> Hi All
>
[quoted text clipped - 4 lines]
> into a recordset, concat the XML tags with this data and then put it
> into a text file using FileSysObj.
You've gone to a lot of unnecessary trouble. You can use the recordset Save
method to save a recordset to an xml file. Later on, you can use the
recordset open method to open a recordset on that xml file.
Oh! reading on, I now see you know about Save ... Open. I would say that you
do not need FildSysObj to save the xml to a file. Use an xml document object
to create your xml (see the data island example here for an example:
http://www.davidpenton.com/testsite/tips/). Use the Save method to save the
xml document to a file.
> This backup proc all works fine, but the problem is when I go to
> restore this backup. I'm using the xml dom object to get the dataset
[quoted text clipped - 15 lines]
> object/process is too slow to handle this amount of data. Is this the
> case?
Yes, it probably is. Nobody ever said parsing an xml file would be fast.
> When I've done the ADO's recordset save option to binary this works
> like lightning and it's xml offering isn't too much slower as well,
[quoted text clipped - 10 lines]
>
> Anybody had this problem and got round it?
Nope. It would never have occurred to me to handle 6000+ rows in an xml
document, let alone in an ASP page. This is the wrong technology for the job
IMO. Don't forget that xml is extremely bulky, so not only are you fighting
CPU usage, you are also consuming memory, much more than your host would
like I'm sure. There's a very good reason your host has the timeout set to
15 sec.

Signature
Microsoft MVP - ASP/ASP.NET
Please reply to the newsgroup. This email account is my spam trap so I
don't check it very often. If you must reply off-line, then remove the
"NO SPAM"