At 10:03 PM 31/08/2004 -0700, you wrote:

>Hi, Helen:
>
>Thanks for looking at this. I just posted (before seeing this) your reply
>to my
>FireBird support question. I considered that a generic issue and this to be
>potentially an IBO issue. Am I wrong?
>
>Also, I completely rewrote the routine I was using to do the ml_path
>update. This
>is really a completely different problem (or is it?)

No, it's the same problem.

>Maybe its all about my transaction set up?

Perhaps, but there's no information about it.

>The issue is simply trying to update a field in a record which may have a
>number of children associated with it, which they too, need updating. I
>accomplished the
>code to do that, but the simple fact of POSTing the changes of that first
>record
>is way too slow.

Clarify what you mean by "posting the changes of that first record."

Also clarify what you mean by "move a node". It looks as if you are using
some kind of independent system of dotted codes for defining the
hierarchical structure, which is making this thread very confusing. In
your design, what's the difference (logically) between moving a bunch of
children from one FK parent to another and moving the same bunch of
children from one "path node" to another? If this "path node" (ml_path) is
meaningful in some way (from the POV of data structure) then how is this
"meaning" implemented in the table structure? (My thoughts on that - "with
great difficulty".)

Structure aside - transaction settings are going to make differences to
what one user can achieve in a multi-user setup, but treeviews are not a
suitable vehicle as an interactive editing interface in a multi-user
environment.. If User A has an update pending on a certain record, then
User B is going to encounter a conflict trying to update any part of that
"family". Any single row involved is itself also involved in other
dependencies. Hence, while tree structures are great for reads, for an
editing interface their beauty is far outweighed by their capacity to up
tie up large networks of interrelated rows with locks and waits.

>Again, can you forget what I wrote initially (in Firebird
>support) for now and treat this as a separate issue? Simply, what can make
>a POST of a single record slow?

Do you see yet that the slowness isn't a separate issue?

>The code I posted (in this IBO group) was only the first level of the update,
>i.e. the actual node that was dragged and dropped in the tree. That code
>goes on
>to check if the node has children, then calls a recursive routine to deal with
>all the potential children. The slow POST issue is what's stopping me now.

You'll have to explain what it is that you think is "the slow post issue".

Helen