ODBC data source?  Make sure you use a system DSN, avoid paths using mapped drives, and that the account used for running the Sage service has access.

Yes, it's an ODBC data source setup as a System DSN.  It's connecting to a MySQL database.  This exact same setup has been working for over a decade, it's only the 2023 version that isn't working with it.  I know Sage sees it because setting up a new VI job I'm able to access it and pick my tables and fields and do all the matching like normal.  Only happens when I try to run the job itself.

Where the DSN exists matters.  I can't remember which is which, but make sure your DSN is set up on the workstation and on the Sage server.  Also, the Sage service account matters.  Running as "Local System" won't have any network / database permissions.

Right now I'm on the actual server, with the DSN setup on that server.  The server is running as an administrative user that has all the necessary permissions.  Nothing has changed the way Sage is setup, only that we've upgraded from 2020 to 2023.  It's strange that it sees the DSN, all tables, all fields when I'm in the Job Maintenance, but not when I run the Job itself.  I would think a configuration or permissions issues would affect both steps and not just one.  Very strange.

Does "administrative user" mean Sage admin, or Windows admin?

The way I understand it: when working on the job settings, your interactive Windows login permissions would be used, but when running the job, it is the Windows Service account permissions that matter.  "Local System" has absolutely no network permissions.

We don't use the Sage Service, it is not installed.  The Application is started using the Application Server Config menu the way it has been for as long as I can remember.  The vi job log shows the last run user on the VI Jobs as being the username I log into Sage as, not as a Windows user.  But to answer your question, I'm trying logged into windows as a windows admin, Sage being run by a Windows admin, and logging into sage as a user with full permissions not the actual Sage Administrator user (since it doesn't give you the Sage GUI, just the config options).  Sage 2022 ran on this exact setup with no issues, as does Sage 2020 on another server.  I don't see any new permissions in User setup that I'm missing, none of the options in the new VI Options area affect it.  I'm at a loss here.

For fun I tried running the VI Job from the command line as well.  It doesn't throw any errors there, but it also didn't run because nothing in Sage changed.

Odd.  For running in application mode we usually use the Start Menu shortcut, but from the config program should be fine.

Have you tried running in MAS90 mode (to bypass the service)?  (pvxwin32.exe... run "startup.m4p...)?

No, just running the standard shortcut that the install adds.  I've never launched the actual UI from command line.  I did try running just the VI JOB via command line with: (pvxwin32.exe ..\Launcher\sota.ini ..\SOA\startup.m4p -ARG UIOFF <user> <pass> <company> <vijobid> AUTO)

Unable to open [wdx][ODB]...

I've now seen this in two systems this week, both new on v2023.  One is Advanced 64-bit, and the other is Premium 32-bit (now called Advanced+SQL).

The one today is special because it is a same server upgrade where the only thing that changed was the upgrade from v2019 to v2023.  Everything else is the same (VI job, DSN, database permissions...).

Clicking "On Host" allows me to see the tables / test the query within VI Job Maintenance, but it won't actually run no matter what I do.

• DSN is the correct architecture (for each system) and tests successfully.
• I tried setting a DSN with both Windows authentication and SQL authentication (storing the SQL credentials behind the key icon in Job Maintenance).
• Running As Administrator doesn't help.
• The Sage service is running as a local admin, which also happens to be SQL sysadmin too.

The only thing that worked was running in MAS90 mode, bypassing the Sage service.  It seems like v2023's service is unable to use an ODBC data source for a VI import job.