“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.

I am able to filter based on a date field in Excel just fine.

As I said earlier the issue may be the date format you are trying to use. The ODBC expects YYYY-MM-DD for date fields.

You must be using a older version of the ODBC driver. Since version 6 (released 2016) of the PxPlus SQL ODBC driver it supports dates with or without the date being escaped.

The ViewLib= setting should be to the directory where you can find libpvx.so file. So if your PxPlus is installed at /opt/myapp and the libpvx.so is /opt/myapp/libpvx.so then the ViewLib= configuration setting should be ViewLib=/opt/myapp

Another issue could be the activation/license of the PxPlus where we are using the view library from is not active. Views won't work if the PxPlus where the view lib is from is expired or has no activation.

PxPlus products do not automatically update so something else on the system must have changed. If you can figure out what changed that will help identify the issue.

Maybe the activation expired?
Maybe someone made a configuration change and moved files or changed permissions etc?
New security or antivirus software/rules preventing something from working?

I Just tried updating a field in a SQL Server database with a non PxPlus program. The field was defined as decimal(10,2) and I set it as 55.123456789. It is now in the DB as 55.12.

I think this confirms that this is SQL Server behavior or more likely SQL behavior.