One of the most important thing in n-tier programming is that your business object should only return small amount of data. Try to do all your processing in the business logic and then the speed wont be a factor back to your form.

ADO can handle large amount of data but again you should always keep your resultsets to a minimum size.

Stephane

>XML is nice in theory, but in practice, it's horribly slow. :( I tried that in another app. It's just not designed to handle tens of thousands of records. I thought passing it a cursor name to put it in was being clever, but, unfortunately, it can't see the cursor. I don't know anything about ADO. Can that handle a lot of data?
>
>Thanks,
>
>Michelle
>
>----------------------------------------------------------------------------------------
>
>>I do that all the time. You can still acheive it using maybe ADO or XML. So your global object can return XML or a recordset object and your form can call your global object methods and then use XMLToCursor or RsToCursor.
>
>---------------------------------------------------------------------------------------
>
>>>As I said in another post, it's a global object and re-creating it in each form defeats the whole point of having a data gathering object. I was trying to centralize the code that accesses these tables so if the tables change, I only need to change the code in one place. But it looks like that isn't possible. So much for my attempt at de-coupling the data from the forms. I guess that just doesn't work.