>Hi george,
>
>>I'm not sure, but if I were to start looking anywhere, it would be at the SQLDMO object. Of course, if it (the licenses in use) were available, you'd have to be able to connect to the SQL Server as an administrator.
>
>>SQL Server licensing comes in a couple of flavors, so it's difficult to know what your scenario is. There's excellent coverage of the licensing possibilities in "Inside SQL Server 7.0". If you exceed the license count, SQL Server will throw error 18458, which means all available licenses are in use. It would probably be easiest to trap that error.
>
>Part of the problem is that probably we don't have anything to say about configuring the SQL server, and not about licences at all. Customers could have a 1000 SQL server licencenses, but if they purchase only a 5 users license for our application, they should be limited to 5 users. I can't expect customers to have a SQL-server for our product only, so we cannot restrict administrators to hack into our server side data and procedures.
>
>I think Larry has made an interesting point, which in fact may work.
>
Walter,

OK, I see now. You're worrying not about SQL Server licenses, but rather user licenses of your product. Larry's (and Doug's) solution will work, but does have a draw back.

Consider the company I work for. We have many applications at six different facilities, each with its own local server and hooked into a WAN. We also have an SQL Server server. Even though we wouldn't, there'd be nothing to stop us from buying one 5 license copy of the application and distributing it to 5 individuals at each of the facilities