Posts Tagged ‘SQL Server’

Recently in one of my Virtual Machine (VM)s I received the above error message when trying to connect to a SQL Server which I used to connect on other times.

image

After having a look I found that the trust between my virtual machine and the domain was broken. You can find the status of the secure channel by using the PowerShell command Test-ComputerSecureChannel.

image

This will also be evident when you try to login to the computer using a domain account. It will generate the following message.

image[6]

To fix this you can try using the below methods.

1. PowerShell

Use the command Test-ComputerSecureChannel.

If your current login has the required access in the domain you can use the below command.

Test-ComputerSecureChannel –Repair

If you need to use another account than the current logged user then you need to use the –Credential parameter when calling the command.

Test-ComputerSecureChannel –Repair –Credential MyDomain\MyUser

2. Joining the domain again.

This will also get fixed by removing the machine from the domain and adding it back. Before removing the computer from the domain make sure you have access to a local administrator account on the computer. Otherwise you will not have a way to login to the computer.

This can be achieved by going to computer system properties,

  1. removing the computer from the current domain,
  2. restarting the computer.
  3. adding the computer to the domain again
  4. restarting the computer

To avoid the two restarts you can try using the following PowerShell commands.

$myPC = Get-WmiObject Win32_ComputerSystem
$myPC.UnjoinDomainOrWorkGroup("Account Password", "Account Username”, 0)
$myPC.JoinDomainOrWorkGroup("Domain", "Account Password", "Account Username", $null, 3)
Restart-Computer -Force

Advertisements

By using the following query you will be able to get all the tables with at least one record in the selected database. It will be handy when you needed to get an idea of the number of records in a database. This uses two SQL Server system views, namely SysObjects and SysIndexes.

  1. SELECT sysobjects.name AS [Table Name],
  2.         MAX(sysindexes.rows) AS [Number of Records],
  3.         sysobjects.crdate AS [Created Date],
  4.         sysobjects.refdate AS [Referenced Date]
  5. FROM sysobjects
  6. INNER JOIN sysindexes ON sysobjects.id = sysindexes.id
  7. WHERE sysobjects.xtype = ‘U’ — Filtering all the User Tables.
  8.     AND sysindexes.rows > 0 — Getting all the tables having at least one reoord.
  9. GROUP BY sysobjects.name,
  10.     sysobjects.crdate,
  11.     sysobjects.refdate
  12. ORDER BY 2 DESC — Ordering by the number of records in table.

 

Above query will bring the following results on the Northwind database.

image

By now as you know, in this post I am going to discuss about two SQL commands we use regularly to clear data in our tables.

Usage

  1. DELETE FROM TABLENAME
  2. TRUNCATE TABLE TABLENAME

Even though they do a similar thing, there are some differences which makes them unique commands.

 

DELETE

TRUNCATE

1. Considered as Data Mining Language (DML) statement. Considered as Data Definition Language (DDL) statement.
2. Can be used to delete all or part of data in a table. Will delete all the data in a table.
3. Will log the actions. There will be no logging on record deletion.
4. Will use more locks. Will use fewer locks.
5. Will use more resources. Will use less resources.
6. Slow. Fast.
7. Will not reset the identity seed. Will reset the identity seed to 0.
8. Can be used to delete data in tables having relationships. Cannot use in tables having relationships.
9. Can be used in tables involved in log shipping or replication. Cannot be used in tables involved in log shipping or replication.
10. Transaction can be rolled back. No rollback.
11. Table may keep the empty pages. Can be released by running, SHRINKDATABASE (Database Name). Data pages related to the table will be de allocated and returned to the system.
12. Related Triggers are fired. Triggers are not fired.

 

If you used DELETE to fully remove all the records, you can reset the identity value by running the following command.

  1. DBCC CHECKIDENT (TABLENAME, RESEED, 0)

If you do have some rows left in table, simply replace 0 with the last identity column value. For example if you put 5 instead of 0 then the next record inserted into the table will have an identity column value of 6.

If you jus need to check the current identity value just use the following command.

  1. DBCC CHECKIDENT (TABLENAME, NORESEED)

UPDATE with JOIN

Posted: January 30, 2012 in SQL Server
Tags: , , , , , ,

If you need to update data of a table (DestinationTable) with data of another table (SourceTable) there are 3 ways you can get this done in SQL.

Method 1

This is the most common and simple way with using a sub query.

  1. UPDATE DestinationTable SET DestinationColumn =
  2.     (SELECT ValueColumn FROM SourceTable WHERE DestinationTable.MappingColumn = SourceTable.MappingColumn)

 

Method 2

This users the most common FROM clause to join the two tables as shown below.

  1. UPDATE DestinationTable SET DestinationColumn = SourceTable.ValueColumn
  2. FROM SourceTable
  3. WHERE DestinationTable.MappingColumn = SourceTable.MappingColumn

 

Method 3

Last method mentioned below uses the join clause to join both the tables to make the update happen properly.

  1. UPDATE DestinationTable SET DestinationColumn = SourceTable.ValueColumn
  2. FROM DestinationTable
  3. INNER JOIN SourceTable ON DestinationTable.MappingColumn = SourceTable.MappingColumn

 

Hope these helps.

Recently after restoring a database backup which I got from another server I repeatedly encountered an error when logged in using a user who is given permission. But when ‘sa’ account is used I could work with the database without any problem.

The error message was “The database DATABASE NAME is not accessible. (ObjectExplorer)” which was not helpful since it didn’t give any clue to figure out the issue.

image

Later I found that the issue is because the user in the restored database is not properly mapped to the user in the new server and the resolution for this is to run the stored procedure sp_change_users_login to correct the orphaned user.

  • sp_change_users_login ‘update_one’, ‘USER’, ‘LOGIN’ – Links the given user in the current database to the specified login.
  • sp_change_users_login ‘auto_fix’, ‘USER’ – Links the given user in the current database to the login having the same name in the current server.

After running this you will be able to access the restored database without any issue using the mentioned database user.

Have you noticed that with the default settings of SQL Server 2008 R2 you cannot use the design view to edit and save table changes which requires table to be recreated. But if you used earlier SQL Server installations you should remember that this functionality was possible. When you try to save such a table you will see an error similar to the following in SQL Server 2008 R2.

But the good news is that we can enable this functionality by going to SQL Server options.

Click Tools –> Options and expand Designers node and select ‘Table and Database Designers’.

Then uncheck the option ‘Prevent saving changes that require table re-creation’ and press OK.

Now if you try to save the table changes SQL will do the alteration without any complains.

Today when I tried to install SQL Server 2008 R2 I couldn’t change the shared feature installation directory in the setup. Both the textbox and browse button were disabled restricting me to select the desired path.

After sometime I found the cause for this. It is because there were some SQL related programs already installed in my computer, because they are there the SQL setup uses the same directory to setup the rest of the programs.

If you need to relocate the install directory then simply you need to uninstall all the SQL related programs using Programs and Features and re-run the SQL Server setup. Then the browse buttons will be active enabling you to select an alternate location.