Hi Ben,

Check out the pxpsqlsvr.conf.sample file that came with the installation for an example and a description.

You can also read the documentation about the new catalog setup for the server here https://manual.pvxplus.com/?odbc/configuration_procedures/server_settings_unix_linux.htm

Also for clarity here is an example from one of my pxpsqlsvr.conf files

catalogs:
default=*[/myapp/data][][]

In this example I defined a catalog named default which pointed to the data dictionary located at /myapp/data and it does not have an INI file or prefixes

In you ODBC client DSN under the server tab you would then specify default as the catalog name to connect to data from the /myapp/data dictionary.

This is so a server could define multiple catalogs and so that clients do not have to know anything about the server or where the data is on the server.

My Windows is also 64-bit.

I tried PxPlus 2017 (V14) and I still do not see a delay.

Are you using WindX? If so what OS is the server running on?

I would suspect something to do with your setup as I am not seeing this issue here.

The WindX Auto Download I mentioned is actually two features: one is what you already tried the dynamic download, the other is static download. I think static download is more helpful in your case as you could have all your images in a directory and in the sync.conf file specify you want that directory synced. Thus a client system would always have that directory downloaded the first time it connects. If you ever update any of the images or add new images all the clients will get updated the next time they connect.

If you still want to go the DLL route you have to be aware of how PxPlus deal with resource DLLs. oldimages.dll is an internal use DLL you can't open it up and add your own images to it. You would need to create your own DLL with your images and name it PLUSLIB.DLL and put it in the same directory as the pxplus.exe. PxPlus requires that the first resource DLL must be named PLUSLIB.DLL. You can have a second resource DLL and name it what you want but then you have to tell PxPlus about it via the INI file or the 'OPTION' mnemonic. This is documented here https://manual.pvxplus.com/?pluslib1/sect1.1/c.htm

A new feature introduced in a Windows 10 update is Windows Subsystem for Linux (WSL). WSL lets users run a Linux environment directly on Windows without the need of a virtual machine. A few different Linux distributions are currently supported: Ubuntu, Debian, openSUSE, SUSE Enterprise, and Kali.

PxPlus will install on WSL but it will not function 100% correctly. The problem is that WSL is not a complete Linux environment and does not support all of the necessary OS functions needed by PxPlus (https://github.com/MicrosoftDocs/WSL/blob/live/LTP_Results/15014/Syscalls.txt). In particular, PxPlus is not able to do file or record locking when running under WSL. That being said, it is possible to run PxPlus on WSL if you are only trying to do some basic testing with a single user.

According to Microsoft, the WSL is designed with the purpose of running Linux command line tools directly on Windows. It was not designed to be a full Linux environment and run all Linux applications or any production applications (https://docs.microsoft.com/en-us/windows/wsl/faq#can-i-run-all-linux-apps-in-wsl).

I would check the Windows firewall on that machine.

I would also look into the antivirus/internet security software that machine is running.

I hope that helps.

If you are not getting an error and the eraseit argument is 1 then it should delete the files from the Outbox/new directory.

It erases the file here when I do a test with PxPlus 2018. Maybe there is something off with how you are calling *web/email. Can you include your line of code that does the call. Make sure to redact the username password for your smtp2go account. Also include what the value of any variables are.

Can you also try to copy the *web/email and *web/smtp programs from PxPlus 2018 to make sure it is not an issue that was already fixed, or a issue caused by in in-place upgrade, or an issue caused by custom changes.

I haven't tried this and don't know if it will work but have you tried specifying ftps:// and the port when using *web/ftp.

CALL "*web/ftp;receive", "ftps://vendorServer:990", user$, password$, 0, "someFile.ext", download_dir$, case$, result$

FTPS is just FTP+SSL and behind the scenes we use curl which supports FTPS so it may be as a simple as that. If that doesn't work likely we would need to update the utility to try to support it. In which case I recommend creating a wish list forum post so we can gauge interest.