Hi Christian,
On 2017/07/21 16:28, Inoue, Hiroshi wrote:
Hi Christian,
Thanks for the report.
It would take some time for me to examine it.
Could you please try the test drivers 9.6.0401 at
http://www.ne.jp/asahi/inocchichichi/entrance/psqlodbc/ ?
regards,
Hiroshi Inoue
regards,
Hiroshi Inoue
On 2017/07/20 23:07, Christian Ullrich wrote:
* Hiroshi Saito wrote:
We are pleased to annouce the release of psqlODBC 09.06.0400.
Hello,
this release changes the behavior of linked tables in MS Access 2016 (x86). With 9.6.310, all is well, with .400, for some tables the data looks good, some are entirely filled with "#Deleted".
Most interestingly, however, for some tables, exactly 9 out of every 10 rows in datasheet view are "#Deleted". Specifically, there are always nine rows like that, followed by one with valid data. If I change the sort order of any column, I get a screenful of valid rows, except for the selected row; that one stays at "#Deleted".
Changing sort order always jumps the view back up to the first row; when I scroll down, everything below the first page is still similar to before; nine rows #Deleted, one row valid, repeat. The pattern resumes at the page edge, i.e. if the window does not show a multiple of 10 rows the valid rows after scrolling down will be different ones than before.
I have switched back and forth between .310 and .400 a few times, with reproducible results each time.
There is no apparent correlation between .400's behavior for any given table and the content of that table. ISTR that Access likes timestamp columns for identifying rows; none of my tables have any.
The behavior is the same with default data source options and with these nondefault options:
- "Row Versioning" enabled
- "True is -1" enabled
- "Bools as Char" disabled
In my experience, these settings are necessary for Access to work at all.
Screenshot attached