>>>>>>>Succumbed ?
>>>>>>
>>>>>>:-}
>>>>>>Doesn't take me long to get bored with lying by a pool.....
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>What do you mean by "computes the total of a document that can contain up to a few hundred lines."
>>>>>>>>What document? What computation ?
>>>>>
>>>>>And we don't want you to be bored now do we?
>>>>>
>>>>>So here's information that will keep you from away from the pool ? I think not :)
>>>>>
>>>>>The document could be an order. The computation is the total invoice, the vat, the amount without vat.
>>>>>The business rules are
>>>>>- the client has a vat profile (you have belgian clients, EU clients or Exports, clients that are not subjected to vat .... the Belgian vat codex is quite a thick book).
>>>>>- the client has an default discount
>>>>>- the client has specific discounts on specific items
>>>>>- the item is subjected to a specific vat rate
>>>>>- some items overrule the clients discount.
>>>>>- ... and here's the kicker, vat needs to be rounded up to nearest (Euro)cent.
>>>>>
>>>>>So in my VFP inherited way, I created the ad hoc objects that implement the rules (including data access). It meant that I access multiple tables for each line of the order. Looked like a good idea as it warrants very clear and manageable code.
>>>>>
>>>>>The problem is that my VFP days are over, I have to do this the "right" way, which would mean that I need to access the db once and then apply the rules for each line without accessing the db.
>>>>>
>>>>>But while the order is being entered, the client wants to see the totals, the vat displayed in real time.
>>>>>
>>>>>So I end up with the lines in a dataset.datable that is submitted to dvg. And that is the information taht i need to "join" to actual tables to get myself an ado.net datatable, that I would then scan through to compute the totals. I guess that would go faster because for say 100 lines I only would go once to the db, whereas now I'm gong like 500 times, which on an access db is (that is my assumption) kind of sllllloooowwwww.
>>>>>
>>>>>Unless I hear anything more sexy I will implement Borislav's suggestion whereby l compile a huge sql statement (including every key) and submit that to get to my dataset.
>>>>>
>>>>>Thanks for caring, and enjoy the pool :)
>>>>
>>>>Ta.
>>>>I don't think it's possible for one to recommend a specific approach without a lot more detail as to how the database is structured.
>>>>However, as John suggested, you can use Linq to Dataset to do local lookups etc. See if this can give you some ideas:
>>>>http://msdn.microsoft.com/en-us/library/bb386977.aspx
>>>
>>>My Backend is MS Access; I don't think linq is an option.
>>>
>>>But tell me, isn't there a way where I can dump my datatable "as is" in a temporary table into the db and then join that? I would then delete the table when I'm done (I promise).
>>
>>What I was suggesting was 'Linq to Datasets' - you still use basic ADO.NET to retrieve data from the backend (whatever that may be) then, as John has expanded on, use Linq-Datasets to query the resulting tables.
>
>Yes, I understood that (now). But my problem was to find a way to really join a datatable in memory with tables in the backend. It seems that to dump keys in an in() clause in sql is the way to go. It works when you just have a set of keys, not sure how to deal with that in more complex situations.
>
>Once the data are in memory, Linq seems elegant, but kind of overkill no?
No
> as (if I'm right) you need to redefine your database structure.
No
>I found that the dataset.select method more effective for small ad hoc uses.
So you tried using Linq ?

Constructing the filterexpression for DataTable.Select() is far more limiting and error prone than using a Linq constructed query.
By all means use the former if you are familiar with it and need code out-the-door quickly - but I'd *really* suggest taking the time to understand and try the Linq approach.....

>
>Anyway, thanks a lot for your support and kind regards,
>
>Marc