https://bugs.documentfoundation.org/show_bug.cgi?id=157916

Julien Nabet <[email protected]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[email protected],
                   |                            |[email protected]
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |NEW

--- Comment #4 from Julien Nabet <[email protected]> ---
On pc Debian x86-64 with master sources updated today, I could reproduce this.

I noticed this on console:
warn:connectivity.parse:24957:24957:connectivity/source/parse/sqliterator.cxx:2025:
Adding error com.sun.star.sdbc.SQLException message: "The database does contain
neither a table nor a query named "Commandes". at
/home/julien/lo/libreoffice/connectivity/source/parse/sqliterator.cxx:2018"
SQLState: HY000 ErrorCode: 1000
    wrapped: void message: "at
/home/julien/lo/libreoffice/comphelper/source/misc/diagnose_ex.cxx:66"

Lionel: after some debugging, I found that in
OSQLParseTreeIterator::impl_locateRecordSource, LO searches the full table name
and not just the table name.
I tried this locally and it worked:
diff --git a/connectivity/source/parse/sqliterator.cxx
b/connectivity/source/parse/sqliterator.cxx
index a89d631e256b..a42fbadf420e 100644
--- a/connectivity/source/parse/sqliterator.cxx
+++ b/connectivity/source/parse/sqliterator.cxx
@@ -369,8 +369,10 @@ OSQLTable OSQLParseTreeIterator::impl_locateRecordSource(
const OUString& _rComp

         // check whether the table container contains an object with the given
name
         if ( !bQueryDoesExist && !m_pImpl->m_xTableContainer->hasByName(
sComposedName ) )
+        {
             sComposedName = lcl_findTableInMetaData(
m_pImpl->m_xDatabaseMetaData, sCatalog, sSchema, sName );
-        bool bTableDoesExist = m_pImpl->m_xTableContainer->hasByName(
sComposedName );
+        }
+        bool bTableDoesExist = (m_pImpl->m_xTableContainer->hasByName(
sComposedName ) || m_pImpl->m_xTableContainer->hasByName( sName ));

         // now obtain the object

@@ -404,7 +406,12 @@ OSQLTable OSQLParseTreeIterator::impl_locateRecordSource(
const OUString& _rComp
                 impl_getQueryParameterColumns( aReturn );
             }
             else if ( bTableDoesExist )
-                m_pImpl->m_xTableContainer->getByName( sComposedName ) >>=
aReturn;
+            {
+                if (m_pImpl->m_xTableContainer->hasByName( sComposedName ))
+                    m_pImpl->m_xTableContainer->getByName( sComposedName ) >>=
aReturn;
+                else
+                    m_pImpl->m_xTableContainer->getByName( sName ) >>=
aReturn;
+            }
             else
             {
                 if ( m_pImpl->m_xQueryContainer.is() )

Any thoughts here? I mean, is it an ugly hack and you got in mind an hint for a
a cleaner fix or does it seem reasonable?

-- 
You are receiving this mail because:
You are the assignee for the bug.

Reply via email to