issue 112706: can I help?

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

issue 112706: can I help?

Terrence Enger
Greetings,

I am trying to dig a little deeper into the first of the assertions
"bookmark not found", for which I created issue 112706
<http://www.openoffice.org/issues/show_bug.cgi?id=112706>.  Here are
some observations from a non-product build of DEV300_m83.

Several levels of the call stack seem to be trying to position to the
beginning of the result set.  At least that is my naive conclusion
from things like "absolute" in function names and parameter
_eCursorPosition and from parameters row and _nOffset with value 1.

When we get to backtrace frame 17, there is still "absolute" in the
function name ( connectivity::OSkipDeletedSet::moveAbsolute, source
file connectivity/source/commontools/TSkipDeletedSet.cxx line 217 ).
Within that function, line 178 reads

    if((sal_Int32)m_aBookmarksPositions.size() < nNewPos )

, and size() returns 1.  The function concludes that the bookmark is
already known and calls connectivity::odbc::OResultSet::move
(connectivity/source/driver/odbcbase/OresultSet.cxx) with second
parameter, _eCursorPosition, connectivity::IResultSetHelper::BOOKMARK.

OResultSet::move fails to find a matching bookmark (after 0
interations through the loop starting at line 1600) and raises the
assertion.

Eventually, my query displays 0 rows, contrary to my expectations.


Is there anything I, a relative newbie, can do usefully here to help?


Cheers,
Terry.



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: issue 112706: can I help?

Frank Schönheit
Hi Terry,

apologies for us ignoring your question for so long ... I don't really
have good excuse except laziness or something equally ... self-bashing,
so I don't even try ...

Just in case you're still interested in a response:

> OResultSet::move fails to find a matching bookmark (after 0
> interations through the loop starting at line 1600) and raises the
> assertion.

I think this points to the problem here. Well, into its direction, at least.

m_aPosToBookmarks is expected to be filled by this method, too. I'd
expect to find calls to OResultSet::move with a FIRST and possibly
subsequent NEXT parameters. In those calls, the map should be filled. If
the method is not called, then it could mean the method is not called -
in this case, the problem lies up the stack, again. If the method is
called, but the bookmark map is not filled (which I assume), this would
mean that m_nUseBookmarks is SQL_UB_OFF.

This parameter is set in Statement::setUsingBookmarks. Since
OResultSet::move is called with a bookmark request, this means the
layers above it assume the result set supports bookmarks - which means
they also should have called setUsingBookmarks on the respective statement.

If they *did* call it, with the proper value, but subsequently, the ODBC
driver returns another value, this means that either setUsingBookmarks
didn't deliver the wrong result to its caller ("no success"), or the
caller didn't respect the result, or the ODBC driver didn't deliver the
proper result.

If setUsingBookmarks has not been called before, then again the bug is
in the upper layers, I'd say - since then they're requesting
bookmark-based movement from the result set without enabling bookmarks
at the statement.

So, those would be the next things you could check: Is m_aPosToBookmarks
filled? If not - why? Is setUsingBookmarks called? With which
parameters, and which result? Does the value passed to setUsingBookmarks
match to what later on is retrieved to initialize m_nUseBookmarks?

HTH

Ciao
Frank

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: issue 112706: can I help?

Terrence Enger
On Mon, 2010-11-22 at 21:58 +0100, Frank Schönheit wrote:
> Hi Terry,
>
> apologies for us ignoring your question for so long ... I don't really
> have good excuse except laziness or something equally ... self-bashing,
> so I don't even try ...

No apology necessary.  I have not been accomplishing much myself.
Still, let me refrain from further self-bashing, lest we start to
reinforce each other's bad habbits. <grin attitude="wry" />
>
> Just in case you're still interested in a response:

I was indeed interested.  With the pointers you provided, I even hoped
to be able to make a contribution, but I see that the problem is not
evident in DEV300_m92.  I have marked the issue FIXED.

Thank you for your patience and for being willing to guide a noob.



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]