Another option would be to use the PxPlus Google Sheet object. As long as the Linux machine has access to the internet you can setup a google account with API access and then write a program that uses that google account to generate a google sheet (spreadsheet) and then export/download it as a xlsx file.

https://manual.pvxplus.com/?Google%20Workspace%20Objects/App%20Setup.htm
https://manual.pvxplus.com/?Google%20Workspace%20Objects/Google%20Sheets%20Object.htm

Journalization is not supported for files with extended length records. See the note at the top of the documentation (https://manual.pvxplus.com/?Data%20Mirroring/Enabling%20Journalization.htm)

We have a wish list item looking at adding support for this. If it does get supported there may be limits on how large of a record length is supported with journalization.

If you want to create a Excel spreadsheet without Excel you can use Google Sheets via a Google Sheets object to create the spreadsheet and export it as an .xlsx file.

The constructor requires a Client ID and Client Secret, both of which must be obtained from Google via the Google API Console. See Google API App Setup for detailed steps.

Example:

x=NEW("*obj/GoogleSheets",clientID$,clientSecret$)
!
! Wait for user to complete Google sign-in and allow PxPlus access
INPUT "Press any key to continue after logging into Google account and allowing PxPlus access:",*;PRINT ""
!
! Complete the Google Sheets login
x'Login()
!
! Open spreadsheet
path$="Commissions/JuneCommissions"
if x'CreateSpreadsheet(path$)=0 then MSGBOX "Couldn't find "+path$
!
...
! add things to the spreadhseet
...
!
! Export current spreadsheet as a XLSX
if x'ExportSpreadsheet("C:\Users\User\Documents\JuneCommissions.xlsx")=0 then MSGBOX "Couldn't export to xlsx"
!
! Close spreadsheets
if x'CloseSpreadsheets()=0 then MSGBOX "Couldn't close spreadsheets"
!
! Drop object
DROP OBJECT x
END


In your first command you pointed to the data dictionary at /facts93. In the second command you pointed to the data dictionary /facts/facts93.

My guess is if you modify your second command to use -d /facts93 you would get what you want.

“REQUIRED FOR OPEN AND ON DATA”  - This means you always need a password to open the file and the file contents are stored encrypted in the file. So if someone were to open a file in a text editor they could not scrape any useful data out of it.

“REQUIRED FOR WRITE AND ON DATA." - This means you can OPEN INPUT the file in PxPlus without a password, allowing you to read it without a password. To do a standard OPEN on the file in PxPlus you need to specify a password, the standard OPEN allowing you to read and write to the file. Also the file contents are stored encrypted in the file. So if someone were to open a file in a text editor they could not scrape any useful data out of it.

Usually you will just want to use “REQUIRED FOR OPEN AND ON DATA” for the more complete security.

As for legacy native encryption vs industry standard encryption performance. Our testing found they performed very similarly. I would strongly recommend using the industry standard  encryption for the better security and ability to have longer passwords. The limitation of only 8 character long passwords for the legacy encryption limits its strength.

In the more recent version of the PxPlus SQL ODBC Driver and PxPlus SQL Server the path to views DLL/Lib is configured on the server side not the client side. On the server you can point it to any directory path to a directory that contains the pvxwin32.dll. A network path can work but it may be less reliable if the connection is not very stable and fast.

If you are using an older version you may be able to resolve your issue by updating to the latest as many bugs have been fixed over the years.

Views require special configuration so the ODBC driver knows where it can find the DLL to process the view.

Check out this answer in the PxPlus ODBC FAQ: https://manual.pvxplus.com/?odbc/odbc_faq.htm#Mark6

Hopefully that will help.

Note that the PxPlus where the pvxwin32.dll is found needs to be properly activated for this to work.

The PxPlus SQL ODBC driver supports that date class.

When using SQL though you use the SQL date format (YYYY-MM-DD) the driver does the conversion to how the date is stored in your file. So assuming your data dictionary has set the date class for the field correctly if you do a SQL query like

SELECT * FROM myTable WHERE datefld > '2022-09-01'

you should get what you want.