You seem to forget that the topic of the presentation was "Introduction". I was told that I would have 45 minutes. You can't address these things in 45 minutes and the certainly don't belong in an introduction....which is meant to present basic concepts.

>That in a very basic way addresses getting the data. However, it does not address the crud operations. Also, I don't need components to grab data. Components serve an important function of providing an abstraction layer for these operations. To a large degree, objects like ADO provide a satisfactory abstraction layer. Still, there are other operations that need to be contended with. For example, how do you handle:

>1. Conflict resolution
>2. Error Trapping and Handling when something goes wrong
>3. New data and their impact on parent/child relationships
>4. Transactions
>5. RI
>

I'm not going to spend any of time addressing these items. Each one alone could take several Wednesday night sessions to describe in detail (as you have asked). I don't have the time, nor the desire to go into it. Based on your past history, I could do this and you would still find fault with my response. If you feel that you have the "correct" answers, perhaps that should be the focus of your next book, where you can provide the solutions to all of us. You seem to forget that there is no one correct way to do many things in programming. If the solution provides the correct results, the solution is correct. It may not be the most efficient, elegant, or maintainable, but it is correct because the results are correct.

>My point in all of this Craig is that this is not a trivial problem. For sure, it is not a problem that can be dished off in a one sentence reply.

I have never said it isn't trivial. I again point out that the topic last night was "Introduction".

>
>No need to reply if Evan takes me up on the offer to do a 2-hour presentation on this in the chat room.

I would welcome that and would like to attend.

>
>Best,
>
>< JVP >