Did you try to open LO from console to see if there were some messages (error or warn messages) ?
Could you attach a dbf file ?

Created attachment 57271 [details]
The example of odb and dbf files. The odb is a connection to dbase. LO recogizes table sample_base.dbf but doesn't see sample_base_bug.DBF.

Here's an example odb file in attachment.

It seems the my terminal doesn't contain anything connected to dbase:

(soffice:23687): Gtk-WARNING **: /opt/libreoffice3.5/program/../ure-link/lib/libstdc++.so.6: version `GLIBCXX_3.4.11' not found (required by /usr/lib64/gtk-2.0/2.10.0/engines/liboxygen-gtk.so)

(soffice:23687): Gtk-WARNING **: /opt/libreoffice3.5/program/../ure-link/lib/libstdc++.so.6: version `GLIBCXX_3.4.11' not found (required by /usr/lib64/gtk-2.0/2.10.0/engines/liboxygen-gtk.so)

I reproduced the pb on pc Debian x86-64 on master.

Then, trying to understand, I thought first it was a pb here in file dbaccess/source/ui/dlg/dbfindex.cxx, function ODbaseIndexDialog::Init()
so I changed the comparison so it ignores upper or lower case but no result.
(however perhaps it should nevertheless ignore upper or lower case) 

Then I found thanks to Opengrok and gdb that the pb was in FDatabaseMetaData.cxx, function ODatabaseMetaData::getTables.
line 288 : if ( sThisContentExtension == aFilenameExtension )
is false because sThisContentExtension = "DBF"
and aFilenameExtension = "dbf"

I must recognize that for the moment, I haven't tried to understand the boolean variables : bKnowCaseSensivity and bKnowCaseSensivity which would permit to change sThisContentExtension to have dbf.

Why is this a bug in the first place? If the proper extension for a dbase table file is ".dbf", why should LibreOffice recognise any other extension? On a case-sensitive filesystem, ".dbf" and ".DBF" are not the same, and could point to two different files.

Julien: bKnowCaseSensivity seems to be meant as "we know whether this filesystem is case-sensitive (or not)" and bCaseSensitiveDir "this directory is on a case-sensitive filesystem".

But indeed, this check seems to be buggy anyway. Even on a case-insensitive filesystem (on Unix, e.g. a CIFS mount of a Windows server), it still sets bCaseSensitiveDir to sal_True, and that's a bug and a real-world problem because e.g. a Windows/CIFS mount may have arbitrary mixed case.

It comes down to line 166 of connectivity/source/drivers/file/FDatabaseMetaData.cxx, function isCaseSensitiveParentFolder:

  if ( 0 == xProvider->compareContentIds( xID1, xID2 ) )

this should return 0 (*only* on a case-insensitive filesystem), but returns non-zero. Stepping it in GDB, it ends up in fileaccess::FileProvider::compareContentIds, which just (case-sensitively) compares URLs... It should rather do a stat() call and compare the respective st_dev and st_ino fields. That is, on Unix. I don't know what it should do on Windows... There is a _stat, but its st_ino is useless (always zero). A few quickly googled links:

http://stackoverflow.com/questions/1866454/unique-file-identifier-in-windows
http://stackoverflow.com/questions/3892592/unique-file-identifiers-on-ntfs-and-object-id
http://discuss.fogcreek.com/joelonsoftware/default.asp?cmd=show&ixPost=42340
http://msdn.microsoft.com/en-us/library/windows/desktop/aa364952%28v=vs.85%29.aspx

The GetFileInformationByHandle / dwVolumeSerialNumber, nFileIndexHigh, nFileIndexLow route seems the most promising?

I had an illumination: dBase files are actually reliably content-sniffable (one can look at a small part of the *contents* of the file and know for nearly sure if whether is a dBase file or not), so we should actually do content sniffing instead of mucking with filename extensions at all.

But the described problem will remain for CSV-style files anyway, so we still need a solution.

(The code involved here, in connectivity/source/drivers/file/FDatabaseMetaData.cxx, is shared between dBase and CSV-style databases.)

*** Bug 58722 has been marked as a duplicate of this bug. ***

No one is assigned or at least has answered for more than 2 years, resetting "Assigned to" field.

Adding self to CC if not already on