When using a normal OE db (being proserve'd) I can get a pretty good idea of the amount of users connected by parsing the license (.lic) file. A customer of mine however uses the MSS DataServer (yes, I know) and connects the schema holder -1 -RO, so there's no server, so no .lic file. Is there any way to get information on the amount of connected users in this scenario? Or do we have to come up with a "homebrew" solution?
Nothing wrong with Oracle/MSS/ODBC DataServer. I have many customers that have been using DS for years without problems. It's a good product when used for it's intended purpose.
The easiest solution is to start the schema holder in multi-user and stop using -RO.
Good for them. SQL Server is a very advanced and innovative database, with a lot of cutting edge features such as referential integrity (enforced on foreign key relationships) and ANSI-compliant isolation levels for database transactions. It is also extremely fast for multi-tier applications where the logic needs to run on a separate server than the database. On the Progress side of things, the engineers who wrote MSS DataServer have done an impressive job, and I've been happy to see them introduce "server-side" joins of multiple tables. You can see that stuff in action on OE 11 and up. (Here is a link: https://knowledgebase.progress.com/articles/Article/What-s-new-in-OpenEdge-DataServers-11-x .In many cases this can provide better performance than when the same ABL is running against a "client-server" connection to the OE DBMS.
Are they on Windows? I would probably just enumerate Progress processes, and inspect/detect if those processes are using the parameters to connect to that schema holder database. Or perhaps it is good enough to use the database log or windows event log and parse to see how many connections are made in a day?
... As a side, I just opened a support case about using "-1 -RO" when connecting to the schema holder database on MSS. One of the Progress tech support engineers on my case just wrote a KB saying this is not supported. But the schema holder database is just another OE database so it seems to me that this claim can be extrapolated to imply that "-1 -RO" isn't ever supported on *any* OE databases. That surprises me because I've used these in the past and I suspect I'll need them again in the future. I thought these options were the only way that multiple ABL clients could access the same local db file which is not "served".
Here is the new KB claiming that "-1 -RO" is "not recommended configuration":
I don't mean to hijack your thread, but if "-1 -RO" is unsupported, you have bigger problems than just identifying the number of users.
Fair enough, but would that require a license for serving the schema holder or is that included with the DataServer license?
Typically the SH is on the same server as the other OE DBs so no additional license is required. I strongly doubt that the DS license includes any WG or EntDB functionality.
[mention:77d0f2ca82a041a08c26cc89b12b968e:e9ed411860ed4f2ba0265705b8793d05] : I suspect it's the "-1" part of the "-1 -RO" that caused some confusion. You can't use both and clearly the -RO takes precedence. The SH is only used for a couple of things at runtime, like checking the CRC of the r-code. AFAIK it is not used in any way after the connection to the foreign DB has been made and the 4GL code is in flight. If I'm wrong (not the first time, not the last time), someone please correct me.
Well, in this case there aren't any OE database servers (licenses). The entire application is using just MS SQL databases (w/ DS) because the customer (of "my" customer) doesn't want OE databases.
You can "proserve" a DB with only DS license. Don't know if that is legal, though. But if it works it should be.
Paul, it's hard to know what is used at what time, but the SH is also used to translate things (table names, column names, data type names, column positions, etc) to the foreign database . I don't know if that happens at program load time or when the data access instruction is about to take place.
[mention:bb539eee062a471eadc1c7b9fe054dfa:e9ed411860ed4f2ba0265705b8793d05] all that stuff should be in the r-code. Again, I'm fairly confident that at runtime, the SH is used to do a CRC check of the r-code versus the accessed tables and that's it.
It should be possible to answer that question by looking at CRUD stats in the SH.
At least part of that is not permanently in r-code. If I change database name, schema name, table name or column name in SQL Server I just need to update the SH mappings. Not need to recompile.
But except for some few placeholders I believe the SH is of little use.
You can change the table and column names in the SQL DB and the SH and the r-code compiled under the previous table/column names still works? I.e. your code says "for each customer: displ customer.name" and you change the customer table name in SQL to cust and the name field to custName, and the r-code still works as long as you update the SH!?!
The DB name and schema name are provided in the ODBC DSN IIRC. The connection string points to the name of the DSN to be used by the DataServer.
Weird.
Yep, I've done that before and tried it again in 11.7.2 right now. This is the statement sent to the database after updating the database:
SELECT "cust_num", "pais", "name", "address", "address2", "city", "state", "postal_code", "contact", "phone", "sales_rep", "credit_limit", "balance", "terms", "discount", "comments", PROGRESS_RECID, PROGRESS_RECID_IDENT_ FROM "sports"."sports"."cliente" ORDER BY "cust_num"
Notice the second field "pais", the portuguese word for Country (actually there is a acute accent on the I when you write it properly), and the table name is "cliente". It was a standard sports.customer table before. The very same r-code.
The schema name also comes from the Schema Holder, from the "FOREIGN OWNER" atribute. The database name is more complicated because you connection parameters, your ODBC settings and your "QUALIFIER" in the SH can influence it.