In the management portal, go to System Administration, Security, Applications, Web Applications and find your application. Under security settings, disable Unauthenticated, and enable Password.

Then, when you send your requests, you need to include a base 64 encoded basic authentication header with the username and password, or on the end of the URL include ?CacheUserName=username&CachePassword=password. Keep in mind, though, that if you aren't using HTTPS, you could end up transmitting a username and password in plain text or in a very easily decrypted way.

If you want only specific users to be able to access the API, consider creating a new Resource then setting that resource as the Resource Required in the security settings, then only giving that resource to people who need to access the API.

That shows me what I wanted. Thank you!

My use case has to do with change logs on our development server. Having looked at your and Lorenzo's answers, I've got a class set up with an objectgenerator method. It looks at the flags, and if there's an "a" or "v" it adds an entry to a versioninfo table I've made that contains a major version number, a minor version number, the username who compiled the class, and a field for notes which we can fill in later. If it's the "a", the new entry keeps the most recent major version and increments the minor version. If it's a "v", it increments the major version and sets the minor version to 0.

Now I can go into Studio and Compile with options adding either of those flags to get the desired results.

This is a pretty immature idea so far. I just wanted to see if it was possible before I went too much further in depth on it.

I decided to try this yesterday, and I got a much bigger boost in performance than expected. The query was very simple, just a select distinct fieldname from table order by fieldname asc. The table contained about half a million records, but there are only about 350 distinct values in this field. Without that order by clause, this query always ran pretty quickly, around .013 seconds, but with the order by on the end, it was taking over 8 seconds to run. I tuned that table, and now even with the order by it's running in about .015 seconds. I was not expecting that drastic of a difference on such a simple query!

I think what you're looking for might be setting the isolation level to read committed. This will make the process wait for the in-progress changes have been committed, though you'll still want to make sure you handle SQLCODE -114 somehow, too. That's the code you get back if there's a timeout waiting for the lock. You should be able to set that using:

%SYSTEM.SQL.Util.SetOption("IsolationMode",1,.oldval)

If you do that before your query, the rest of the process will run at that isolation level.

You can use that same method to set the LockTimeout too, by the way. Default is 10 seconds.

Ideally, that would be the case, but some of these aren't apps we've written and are forcing to log in with a safe user account. They're 3rd-party apps that our users are logging into using their usual credentials to create an ODBC connection. Most of them are reporting tools, but a few are also capable of running queries other than selects.

I think what we'd like to be able to do is determine roles similarly to how you can set up application roles so that the user gets those roles when they log in, we set permissions based on the program being used. Can we do that somehow in ZSTART?