Hi,

This is caused by code that helps you find errors in your data logic. If you declare a parameter for a stored procedure in code that does not match the parameter as it is declared in the actual stored procedure it will throw an exception there because of the debug assert (but only when compiled in debug mode not in release mode). Consider the following C# code:

public static bool Update(
            Guid id,
            string statement,
            DateTime lastModUtc,
            Guid lastModBy)
        {
            SqlParameterHelper sph = new SqlParameterHelper(GetWriteConnectionString(), "mp_SavedQuery_Update", 4);
            sph.DefineSqlParameter("@Id", SqlDbType.UniqueIdentifier, ParameterDirection.Input, id);
            sph.DefineSqlParameter("@Statement", SqlDbType.NText, ParameterDirection.Input, statement);
            sph.DefineSqlParameter("@LastModUtc", SqlDbType.DateTime, ParameterDirection.Input, lastModUtc);
            sph.DefineSqlParameter("@LastModBy", SqlDbType.UniqueIdentifier, ParameterDirection.Input, lastModBy);
            int rowsAffected = sph.ExecuteNonQuery();
            return (rowsAffected > 0);

        }

Note that I have declared the types of the parameters expected by the stored procedure. Suppose I made a mistake the @Statement parameter is actually not declared as NText in the stored procedure but at nvarchar, then it will raise an error at the Debug.Assert. If I change the stored procedure to match the c# code then I also need to touch Web.config to clear the cache because we cache sql parameters. If I change the C# code to match the procedure I have to re-compile and this would clear the cache.

Note also that this error caused by the Debug.Assert will not happen if you compile for release mode (which you should always do for production builds). A different error may or may not happen, the database is somewhat forgiving, if a param is declared as NText but is actually NVarchar(max) it may still work with no error when compiled as release mode because these data types are close enough and sql server is tolerant. But if for example I declare a uniqueidentifier when it is really an int, that will typically throw an error at runtime.

So the Debug.Assert is there to help you find errors in your code at development/debug time so you can prevent errors at runtime.

Hope it helps,

Joe

Hi Desirea,

You should not encounter issues with Debug.Assert on production sites if you compiled for release and have <compilation debug="false" in Web.config on production.

It is really a developer tool. Some more info about it, like when to use it and when not to can be found on this stackoverflow post about debug.assert.

I am constantly trying to improve our documentation, but many things that people have questions about are ASP.NET topics not really specific to mojoPortal other than the fact that mojoPortal is an ASP.NET application. So mainly I'm trying to document mojoPortal specific things, there is already lots of documentation for ASP.NET on the web and I try to link to that as much as possible for questions that are not specific to mojoPortal, but often these questions come up in context of developing with mojoPortal even though the concepts apply to all ASP.NET.

Best,

Joe

No, the SqlParameterHelper has these Debug.Asserts to help developers avoid mistakes in their code, you cannot bypass them in debug mode unless you don't use SqlParameterHelper.

You can write your own ADO.NET code if you don't like our helper methods, else you can pass in all the parameters expected by the procedure even if they are null to avoid the error. I recommend use the helpers and pass in the parameters assigned as DBNull.Value if they are null.

Best,

Joe

the parameters have to be in the same order that they are declared in the stored procedure, if they are not then it is an error in code and the debug assert will alert you to it.