Bug 113296 - Attempting to write to an ODBC-connected Access 2010 database accdb throws an error and fails
Summary: Attempting to write to an ODBC-connected Access 2010 database accdb throws an...
Status: RESOLVED INSUFFICIENTDATA
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Base (show other bugs)
Version:
(earliest affected)
5.4.1.2 release
Hardware: x86-64 (AMD64) Windows (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Database-MS_Access
  Show dependency tree / graph
 
Reported: 2017-10-20 14:58 UTC by Alex Thurgood
Modified: 2019-07-05 08:07 UTC (History)
1 user (show)

See Also:
Crash report or crash signature:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Alex Thurgood 2017-10-20 14:58:05 UTC 
Description:
Using :

Win10 64bit
LibreOffice 5142 64bit
64bit Database Access Engine 2016
64bit Northwind accdb created with MS Access 2016

I can sucessfully setup and open an ODBC-connected Base file that connects to the sample Northwind.accdb database provided by MS.

However, any attempt to write data to a table opened in table edit mode results in an error message :

Error inserting new record
[Microsoft][Microsoft ODBC Access Driver]Invalid bookmark (Signet non valide)

I'm assuming that in fact what is meant here is "invalid cursor" ?



Steps to Reproduce:
See above

Actual Results:  
No new data is written to the table. No changes to the data can be made.

Expected Results:
Table should be writable.


Reproducible: Always

User Profile Reset: No

Additional Info:


User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:56.0) Gecko/20100101 Firefox/56.0
Comment 1 Xisco Faulí 2018-01-17 15:38:05 UTC 
Hi Alex,
Do you reproduce it in previous versions of LibreOffice?
Comment 2 Alex Thurgood 2018-01-22 08:05:58 UTC 
@Xisco : people have previously reported functioning systems with 32bit installations of LibreOffice with the 32bit ODBC connectors on Win7/Win8 and Win10, but I haven't (and won't) be testing such setups.
Comment 3 Alex Thurgood 2018-01-22 08:07:20 UTC 
I can't say whether this is because it is all 64bit specific, or if something has changed in the way our code accesses the ODBC driver.
Comment 4 Alex Thurgood 2018-02-16 09:20:36 UTC 
I can still reproduce this with LO 6011
Comment 5 Timur 2018-10-29 14:24:37 UTC Comment hidden (obsolete)
Comment 6 Alex Thurgood 2018-11-05 12:15:06 UTC Comment hidden (obsolete)
Comment 7 Alex Thurgood 2018-11-05 12:19:38 UTC 
(In reply to Alex Thurgood from comment #6)
> (In reply to Timur from comment #5)
> > Is this not the same as *yours* bug 43187?
> 
> No, bug 43187 is about ADO driver usage, not ODBC.

Having said that, I have no way of telling whether the ODBC driver and the ADO driver call the same code path in the underlying LO code, so who knows...

The only way to really find out would be to use a debug enabled version and trace the calls...as I'm not putting a debug build on my Win production machine, I guess we will never find out.
Comment 8 Xisco Faulí 2019-05-16 11:53:29 UTC 
Hi Alex,
Do you still reproduce this issue in master ?
Comment 9 Alex Thurgood 2019-05-16 12:42:55 UTC 
Hi Xisco,

I can no longer test, I don't have the required set up any more.