Craig..

I totally agree.

However...

The question was asked, and you provided and answer. That brings it into issue. I would have redirected the question to a public forum where it could be addressed in detail.

FWIW, the answer of using a hierarchical recordset is NOT the way to go. This is what you told the person to consider. Grabbing individual recordsets IS the way to go. Still, you have a whole series of management issues to address. This is what your component needs to deal with.

You have a person now who may be trying to employ what you told them to do. No doubt, they will run into issues.

There is no dishonor in this word by saying either "I don't know" or " I cannot address that issue now." The worst thing you can do is give a partial answer. Even worse is giving a partially wrong answer. I suppose the upside is that the person can then only implement part of a bad solution.

Yes, I DID remember that it was an introduction. I think YOU forgot that point.

Craig, if you make the step of presenting in public, you have to accept both the good and the not-so-good. For example, I received some critical comments for not having more formal samples prepared. A legit. comment. I did not rip anybody's head off for those comments. I explained why I did not have more formalized samples. Still, that does not invalidate those comments.

I am afraid the waters are so polluted here that the spirit and the point of this is lost. And I suppose I have to hold myself accountable for that. However, I will also hold others accountable just the same.

< JVP >



>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 >