QuoteIf I have a +20 and -20, is that the *same* user slot.

Yes it means they are both using the same user slot. The +20 session acquired the user slot, the -20 session is using the user slot acquired by the first. This is because they are coming from the same client.

QuoteIf they initiate 2 sessions does this burn off one or 2 slots?

It should use up one user slot since it is the same client.

Running a WindX host/server does not require a Windows Server OS and can be run from Win 11 no problem.

in pxplus request Accept: application/json
in postman request Accept: */*

in postman there is a Connection: keep-alive which is not in pxplus request

In postman there is a cookie header that is not in pxplus

Beyond the body those are the differences it is got to be one of those or we are missing something.

The issue has been resolved. You should be able to call in now.

There is no Captcha utility built-in to PxPlus.

As part of Webster a very basic captcha was built and used for the login process. This code is can be looked at if you want a starting point on how to implement your own. You could also possibly call it yourself (*webster/captcha) if this is for a web application and if you are happy with the simple captcha.

You can also use an existing captcha service like Google reCaptcha. There you would sign-up and get a API key and then you could include the script as per Google instructions if this is a web application. If this is not then you could use *browser to include it in your application.

No the fixes included in the patch where for Windows and WindX only.

By design the Linux PxPlus will

Look for <exename>.ini in current directory

and if not found

Look for <exename>.ini in directory where exe resides

If that is the length of the file why is Postman sending less? What is postman not sending that you are with your PxPlus request?

The size of the content is what I would expect is the issue. If you are sending a request and getting a bad request error maybe the extra 6 bytes you are sending via PxPlus are the cause.

Not sure.

accept-encoding is also lower case?

Accept header is different?

Content length is different?

Are you using the latest version of PxPlus there have been improvements and bug fixes to *plus/web/request over the years?

In the PxPlus request you have

Authorization: bearer yJhbGciOiJIUzIfQ.VDMfa9MhV...

while the postman request you have

Authorization: Bearer yJhbGciOiJIUzIfQ.VDMfa9MhV...

The b in Bearer I would guess needs to be capitalized.

In you *plus/web/request when setting the extra headers make sure you use a capital B.

In that cause you were bang on with your initial guess.

PxPlus can't read beyond the non-extended record portion for keys. So whatever your max record size is will be the limit. So if your max record size is 31000 then data beyond 31000 bytes in the extended record cannot be part of the key.

The limit for the key segment offset is 3839 - segment length.

KEYED "keyoffsettest","[1:1:6],[2:3830:10]",0,-31000,OPT="X"

or

KEYED "keyoffsettest","[1:1:6],[2:3830:10]",0,-31000,OPT="X"

These:

WRITE RECORD (CHAN,KEY="!INSERT INTO [WMPOS].[dbo].[D_INVENTORY] ITEM_NAME ='"+V1$+" ' WHERE ITEM_ID_ORIGINAL ='"+V2$+"'")

WRITE RECORD (CHAN,KEY="!UPDATE [WMPOS].[dbo].[D_INVENTORY] SET ITEM_NAME ='"+V1$+" ' WHERE ITEM_ID_ORIGINAL ='"+V2$+"'")

Should be:

WRITE RECORD (CHAN)"INSERT INTO [WMPOS].[dbo].[D_INVENTORY] ITEM_NAME ='"+V1$+" ' WHERE ITEM_ID_ORIGINAL ='"+V2$+"'"

WRITE RECORD (CHAN)"UPDATE [WMPOS].[dbo].[D_INVENTORY] SET ITEM_NAME ='"+V1$+" ' WHERE ITEM_ID_ORIGINAL ='"+V2$+"'"

The key="!<SQL>" syntax is for reads not writes. For writes you just pass in the SQL as what you are writing.

You read with a key= will work but since it does not return data you do after to ignore the error. I think using a write is better here since it doesn't try to read any response back.

For documentation on what the PxPlus order of precedence is see here:

https://manual.pvxplus.com/?PxPlus%20User%20Guide/Language%20Elements/Data%20Types,%20Literals%20and%20Variables/Numeric%20Values.htm#numeric_exp