SSRS: Slow Report over a Stored Procedure
While working on a report based on the results of a complex stored procedure I encountered what I considered to be a strange behavior. I noticed that when the stored procedure was executed directly the results were returned in seconds and they were returned in several minutes when executed from the report.
After further looking into the execution I realized that the parameters in the report were “prefetched” and analyzed where they were used in the procedure. which took some time. I made a few small changes to the procedure and had favorable results. I declared local variables, assigned them the values that were passed to the procedure and used the local variables within the procedure for filtering the data. The report results were returned in the same interval as executing the stored procedure directly.
SQL: DBCC DBINFO – Last good CHECKDB date
The DBINFO Database Console Command (DBCC) lists some valuable database information.
DBCC DBINFO (<databasename>) WITH TABLERESULTS
A few results of note:
dbi_dbccLastKnownGood – The last date DBCC CheckDB successfully ran without error
dbi_crdate – The database creation date
dbi_dbid – Internal database ID number
Microsoft Dynamics Nav: Prevent User Login
It may be necessary at times, for example due to software data maintenance, to prevent all but a few users from logging into a Microsoft Dynamics Nav database.
There are a few options available for accomplishing this task. If Database Authentication is used, then setting an expiration date will prevent the users from logging in. This can be a tedious task if you have several hundred users. If you’re using Windows Authentication you can remove the user from the Windows List or disable their Windows account (same applies to Windows groups). This also presents an issue if you have a number of users and/or an elaborate set of security roles. Removing the users is an impractical choice that requires the users to be added and setup again. Disabling the Windows login is not a reasonable option as it also disables a user’s access to other resources. Another common thought option is to put code in Codeunit 1 - ApplicationManagement. This sounds logical, but in order for a user to run Codeunit 1 they have to be logged in.
There is another option, which only works for Dynamics Nav with a SQL database. You can create a stored procedure sp_$ndo$loginproc. This stored procedure is executed as a user is “logging” into the Dynamics Nav database. If you raise an error in this procedure the user will not be able to open the database with the Nav client under both Database or Windows authentication.
- Create a table, from within Nav, called _UserLockoutAllow. Set DataPerCompany to No and add a field, Code 20, “User ID”.
- Create the sp_$ndo$loginproc stored procedure:
CREATE PROCEDURE [dbo].[sp_$ndo$loginproc]
@appname VARCHAR(64) = NULL,
@appversion VARCHAR(16) = NULL
DECLARE @cnt integer
SELECT @cnt = COUNT(*) FROM [_UserLockoutAllow];
IF (@cnt > 0)
IF Not (Upper(SUSER_SNAME()) IN (SELECT [User ID] FROM [_UserLockoutAllow]))
RAISERROR ('The system is currently unavailable for scheduled maintenance.', 11, 1)
Adding User IDs to the table will only allow those users to access the database. If the table is empty then everyone can login. Also note that if you add a User ID to the table all logged in users will receive the error and be logged off if their User ID is not allowed to login.