Starting with SA 11.0.1, you can use the Authenticated database and connection property. That should tell you if the connection could be authenticated or doesn't need to be authenticated (value 'Yes) or if the authentication failed ('No'). Note: It does not tell you if the database server is an OEM version (as I had formerly expected).
So, as your app don't try to authenticate, a value of 'No' should tell you that you are running on an OEM version and that there's need for a valid authentication string supplied by the user.
At least that's my understanding, I don't have an V12 OEM edition yet:)
EDIT:
I can confirm Breck's tests with my own non-OEM Servers on V 11.0.1 and V 12.
Unfortunately, the current docs are quite silent about the values of these properties on non-OEM servers. However, the original introduction of these new properties seems to be in 11.0.0 with EBF 1409 with the following readme quote:
================(Build #1409 - Engineering Case #528793)================
A new connection and database property called "Authenticated" has
now been added. The use of these two new properties is as follows:
For OEM servers, once an application has
executed the "SET TEMPORARY OPTION CONNECTION_AUTHENTICATION="
statement, the application can then turn around and execute a "SELECT
connection_property( 'Authenticated')" statement.
If the result is "YES", then the connection was properly authenticated and all is
well. If, however, the result is "NO", then the application can execute a
"SELECT db_property( 'Authenticated')" statement. If the result of this
statement is "YES", then the database has been properly authenticated and
the connection authentication failed because the CONNECTION_AUTHENTICATION
string is incorrect.
If, on the other hand, the result of querying the Authenticated database property is
"NO", then the connection authentication failed because the
database has not been properly authenticated. In this case, the
customer should examine the DATABASE_AUTHENTICATION string to
determine what is wrong.
For non-OEM servers, the result of querying these new properties will
always be "YES".
Note: I remember to have asked for such properties because of problems with a wrongly authenticated connection on a V10 OEM server - something that was really hard to check without these properties. So I guess I have remembered this description. But I seem to be wrong (or the implementation in 11.0.1 and 12.0.0 has changed for non-OEM servers).
Resume:
I guess these properties as implemented are not helpful for your case:(
answered
28 Jul '10, 21:24
Volker Barth
39.3k●354●538●808
accept rate:
33%
@Breck: I am wondering what is the reason behind your attempt to prevent Foxhound from running on an OEM Database Server?
Because I don't want anyone to get in trouble with respect to license agreements. Foxhound does not ship with an OEM copy of SQL Anywhere. Customers are required to obtain SQL Anywhere on their own. AFAIK it is not proper to use an OEM copy intended for use with some other application, to run this application (Foxhound). Perhaps Mr. Kleisath can jump in with a deeper explanation.
And the real reason? When a new Foxhound database tries to make a proxy table connection to the old Foxhound database in order to upgrade the data when installing a new version, the connection attempt gets "Authentication failed" when OEM/Authenticated SQL Anywhere software is being used. Prior to that point (normal use as a web server) Foxhound apparently doesn't see the problem, and I want to tell the user about the problem up front.
@Breck: The alternative being to add an "Authenticate database/connection" command where the user can supply both values? (Well, surely not helpful in the cases where an OEM customer doesn't have both properties available, more meant for the OEM suppliers when testing...)