I can't interpret this message, or figure out whether I should select the
option or not.
My main problem is that my intuition is that checking "upgrade mode" will
perform an upgrade, but the text of the message seems to say that checking
upgrade mode will NOT perform an upgrade.
Since I don't
I have a physical machine H (host) running a virtual machine V. Both are Win
10 64 bit; vmware provides the virtualization.
Symantec EndPoint Protection (SEP) on H is blocking attempts to connect to my
postgres 12 server running on V. I am trying to get it to permit the
necessary traffic.
I'
I have a table that seems to act for some purposes as if I can't add new
records to it. I would like to understand why that is and fix it.
The initial problem was that an MS-Access application using an ODBC driver
(driver and database 64 bit PG 12.0) failed at
DoCmd.GoToRecord , , acNewRec
Thank you for the confirmation on the need for a primary key. I suspected
that, since the GUI needs an easy way to refer to a particular row. I think I
saw such a restriction in the Qt documentation on a different project (just to
be
clear: no Qt involved in this one--just more evidence this
My mail interface (Outlook on the Web) really can't quote properly, so I'll
just do snips.
>"When you create a new table in Datasheet view, Access automatically
creates a primary key for you and assigns it a field name of "ID" and
the AutoNumber data type."
That quote, and the documentation ment
>From: Adrian Klaver
>Sent: Saturday, December 21, 2019 3:37 PM
> This might be easier to figure out if you outline what is going on:
Since I seem to have gone on in my responses, let me do one-line answers before
the fuller ones.
> 1) The purpose of the migration?
Primarily to use currently
> From: Adrian Klaver
> Sent: Sunday, December 22, 2019 10:35 AM
.
> Alright this is the part where I got confused. I think what is going on is:
>1) The immediate change is going to be to Access 2016 on Windows 10 64
keeping the data in Access files(.accdb)
> 2) The long term plan is to mov
n issue is limited to cases
with a server backend. Even the file based data, managed directly by Access,
has foreign key relations in it (I'm pretty sure), and those too could be out
of sync with the Relation objects describing that same data.
I also probably need a better understanding of
