Quick post, aide-memoire, for disabling and then re-instating database contraints in MS-SQL.
EXEC sp_MSforeachtable "ALTER TABLE ? NOCHECK CONSTRAINT ALL"
EXEC sp_MSforeachtable @command1="PRINT '?'", @command2="ALTER TABLE ? WITH CHECK CHECK CONSTRAINT ALL"
When running a SQL script using the command sqlcmd tool if you switch context to another database, by using the “use database” command, then any variables defined before this are lost. A similar thing happens if you use the “go” command to group, or batch, commands in the script.
Create a temporary table, e.g
CREATE TABLE #GlobalVariables (variableOne varchar(30), variableTwo int)
INSERT INTO #GlobalVariables (variableOne, variableTwo) VALUES ('ABCdef', 222222)
Use script variables
:setvar variableOne "ABCdef"
:setvar variableTwo 222222
To access these in your SQL code you would do the following:
UPDATE #GlobalVariables SET variableOne = '$(variableOne)', variableTwo = $(variableTwo)
A link to a blog that can be used as the starting point for those who need to manipulate XML held in MS-SQL.
By default the sproc is disabled, something to do with a security concern.
To enable the procedure run the following in a query window:
EXEC sp_configure 'xp_cmdshell', 1
If that doesn’t work, and it didn’t for me – I’m running SQL Server 2008 R2. Then run the following commands:
EXEC sp_configure 'show advanced options', 1;
EXEC sp_configure 'xp_cmdshell',1
You can then run something like:
EXEC xp_cmdshell 'iisreset'
To get the keys for a table in Microsoft SQL Server use the stored procedure: sp_pkeys
Looking for a column that’s directly referenced by a stored procedure (sproc) then try running this query:
SELECT SProcName = OBJECT_NAME(object_id), Definition FROM sys.sql_modules WHERE definition LIKE '%SEARCH_CRITERIA%' ORDER BY SProcName
This replaces the previous link.
Sound familiar? For some reason I couldn’t log into my admin account, the password was always wrong. I’ve still no idea how this happened but fortunatley if you get to your MySQL DB, either via SQL tools or MyPhpAdmin, there is a way out!
Just run this query against the DB and hey presto it’s all sorted for you.
UPDATE `wp_users` SET `user_pass` = MD5( 'new_password' ) WHERE `wp_users`.`user_login` = "admin_username";
But still none the wiser as to how it happened in the first place. The account doesn’t seem to have been hacked as nothing else has changed.
sp_who for a list of all spids. Then
dbcc inputbuffer(spid) to find out what any blocking spid is executing. If needed you can then
The engines are held in a file on the client PC not in the registry.
Link to an article here.