Update() method - Connection Is closed. A re-org needed?

[Andrew Backer]

.Update() does NOT create a new connection, or re-open the existing
one. It simply uses the old one from LocalContext. This causes an
exception, since the connection is now "closed".

Calling DataPortal.Update(Of MyItem)(instance) works fine, since that
calls DataPortal_Update

I noticed this issue when calling .Update() directly on a Switchable
object. I had used the GetXXX static method to return a single
instance, so it isn't marked as a child.

Solutions:?

1) Fix Update(), and have DataPortal_Update call that directly.
--- only one source of Update() code
--- fixes both methods

2) Fix both, and keep separate
--- seems redundant, but perhaps there are reasons from a template POV

3) Fix DataPortal_Update, and have Update() call that (via DataPortal,
or directly)
--- Possibly breaks stuff if you turn off the Portal option on the
criteria/etc, causing DataPortal_Update to not be generated. Dunno.

If any of these seems ok, I'd be happy to go ahead and do it (once a
new release is out, or in svn).

//Andrew

[Andrés]

Any chance you have any Insert/Update handlers interacting with other objects? Maybe fetching a name value list or readonly collection?
Sometimes when you do stuff like that, the update process sets the connection and then the readonly collection replaces it with it's own. The readonly collection closes the connection and returns to your code. At this point, the next time you access the connection, it's not the one that originated the whole save process, and you get that error.
Make sure you don't have anything like that in your code, and if you do, make sure you restore the original collection into LocalContext after interacting with your other object.

--
Andrés

[Andrew Backer]

I have a single object, a single call to the database, and a single
post-fetch handler (that doesn't touch the database, just over-writes
a local field). It *should* be the same connection, but it should not
matter.

In any case, the Update() call does NOT create a new connection & open
it, as do ALL the data portal methods, which is wrong regardless of
what is happening in between. It is just an oversight that probably
usually works, just not this time, or for me :( . It did throw light
on an area that might take consolidation well, so I think that should
be considered.

To clear something up: If I replace my call to .Update with a indirect
call through DataPortal (the only change), it works. Again, this is
because DataPortal_Update() is called, and that creates a _new_
connection and opens it again.

As for the local context... The data in it gets clobbered with every
DataPortal call, so I wouldn't rely on anything in there between any
two calls on *any* two objects.

//Andrew

[Andrés]

Well, Update() never creates it's own connection (I think there's an exception to that, when you select TransactionType = None for the child object, but I can't recall). It always takes the connection created by the parent. Why this is failing I don't know, but it's something we should definitely look at.
Can you send me a sample xml that reproduces the issue so I can look at it??

--
Andrés

[Andrew Backer]

I use a switchable. In this case it does not have a parent, though it
could. If you make a switchable, with a Get(), then try to
call .Update or .Save, it will fail.

// Andrew

[Andrew Backer]

Someone else just told me that no one uses Switchables, or knows much
about them =) I don't know why, they seem quite useful.

So the .Update is really for the parent to use on the child, and
*should* be working this way. I guess there is just a general
mismatch between the templates and Switchables :(

I do wish you had mentioned the parent connection earlier. I assumed
that all updates were supposed to route through the data portal
methods, which do create the connection. Sorry.

//Andrew