The JavaScript editing functions in CRM are a bit basic, and it is very easy to spend hours debugging a small bit of code by simply looking at it in the native CRM JavaScript edit field.

There is an easier way, just by making a small change to the Advanced Settings in IE and adding a single line to your code, you can have the luxury of stepping through your code, or setting breakpoints just like you would in a grown up language like C# or even C++.

To do this first make sure that Script Debugging in Internet Explorer isn’t disabled. To do this go to the Internet Explorer settings in Internet Options under the Tools menu, and select the advanced tab, and scroll down until you see the "Disable Script Debugging (Internet Explorer)" option. Make sure it isn’t checked.  Press Apply and then close the dialog box.

Next in the block of JavaScript you want to debug in CRM, add the following statement

debugger

This should appear at the point that you want debugging to start, but for ease of use can be added as a first line in the JavaScript block.   Once this statement is encountered it will fire up a list of debuggers that you can use to step through your JavaScript code.

You just have to remember to remove the line or comment it out before you give the changes to your users, otherwise each time they execute your code it will ask them if they want to debug it.

A quick way of selecting a batch of random records from a SQL table is to include the NEWID() function in the WHERE clause. This function generates Windows GUID values and provides for most purposes a resonably random set of results.

Use:
Select top [xx] * from [TABLENAME] where value='sample' order by NEWID()

The above example will return a random sample of xx records with the matching WHERE clause.


Example:
Select top 10 from contact1 where key3='Prospect' order by NEWID()

To discover the network name of the server that SQL is physically located on, the extended stored procedure xp_getnetname can be used.

On its own it simply returns a result set containing the netname of the server, however it can be used within a sql script by including the following code:


declare @netname varchar(100)
exec master..xp_getnetname @netname OUTPUT
print @netname

 

There are two methods to do this either using a TRUNCATE or DELETE command. 
Both have their advantages and disadvantages

TRUNCATE TABLE [TableName]
This method is fast, but should not be used on any table that is used
for replication, or if there are ON DELETE triggers present on the table.
This method will simply remove all the rows in the table in a single operation.

Advantages:
It usually much faster than a DELETE statement.
If you use IDENTITY columns it will reset them.
The wasted space may be reused.

Disadvantages:
You cannot specify a WHERE clause, its all or nothing.
Triggers will not fire.
If the table is replicated you cannot use this method.
If the table has a foreign key it will return an error and fail.
Cannot be rolled back, without a restore.



DELETE FROM [TableName] WHERE xxxxxx
This method works row by row, and fires triggers, and updates the transaction
logs. This method will be slower on large tables than TRUNCATE but should
be the only method you use if you have ON DELETE triggers, or the table is
included in replication.

Advantages:
Triggers are fired for each row deleted.
It works for replicated tables.
You can specify a WHERE clause to remove part/all of the rows of a table.
It can be rolled back without a restore.

Disadvantages:
Speed on large tables.
Recovered space is not immediately reused.
More internal space may be used while deleteing data. An issue if you are removing rows to save space.


Following a DELETE statement the following can be used to reset the table IDENTITY if one is being used.

DBCC CHECKIDENT("[TableName]", RESEED, "reseed_value")

And to recover the wasted space

DBCC SHRINKDATABASE ([DatabaseName]).

A while ago I was faced with the problem of finding the SQL server and database name for a UAT CRM instance that I didn't install. And unfortunately the user who installed it wasn't around and hadn't granted any other users rights in the Deployment Manager Tool, so a quick fix was needed.

After a little bit of research I discovered the database connection strings are held in the following registry hive on the actual CRM server.

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSCRM 

The keys that contain the SQL strings are   configdb,  database,   metabase

Not rocket science really, but useful if you need to quickly find the databases and all else has failed.

A brand new blog with some new posts coming soon........