So there is actually a red screen of death. Microsoft does have an RSOD, it is very rare to see these days. As a matter of fact, it was only visible in a beta version of Windows Vista. Seen here:
There is another RSOD, HP has one too and I saw it first hand today:
This error indicates a problem with your SAS Controller. A firmware upgrade from HP might be able to fix your problem.
Either error is not good, my sympathies.
This is my first screencast, enjoy!
This is a great article to show you how to do it and I give him credit:
http://howto.cnet.com/8301-11310_39-57347395-285/how-to-map-your-skydrive-folder-in-windows-7/
But there is a problem why would you want those files to be exposed to the public???
\\docs.live.net@SSL\IDGOESHERE\^2Public
See the end that says public? Yeah, you don’t want that, change it to:
\\docs.live.net@SSL\IDGOESHERE\^2Documents
This will save it to your documents folder on your Skydrive, much more secure in that not everyone can see your files.
Here is something that works incredibly well.
This is a quick description enter the file names you wish to use. Powershell then reads in all the data and creates a new file by joining all the elements in the char array to a string. It then takes the row and ends it in a carriage return / line feed. Finally it saves the file.
$fileName = c:\file.txt
$newFileName = c:\newfile.txt
$newFile = “”
Get-Content -Path $filename | ForEach-Object{$newFile += [string]::Join(“”,$_[0..149] + $_[154..777]) + “`r`n”}
$newfile > $newFileName
Through the years I have amassed some tips and trick to make SQL Server run more efficiently. For right now, I would like to tell you about some common mistakes that developers make, I know I have made some of these!
Tip 1 – It’s all about the cached execution plan!
Ok so SQL Server has execution plans, big deal, what does this mean to you? Here’s what you need to know, for every query you execute SQL Server determines the best possible way of getting data from the database files. For some very complex queries, the possibilities could be well into the millions! To save time executing repeated queries, it stores the best possible way of executing these queries in a cache.
Those are the details but here is how to take advantage of this. Store the queries you are using in Stored Procedures. This will help SQL Server store the execution plan. There is one secret to this, assign the parameters to local variables within the Stored Procedures!
Tip 2 – Reduce Network Traffic!
You may have heard that Select * is a bad thing well turns out that there a number of reasons. The big one extra packets are getting sent from the SQL Server. Secondly it also increases disk I/O on the server. In SQL Server, less is more. Also if you SET NOCOUNT ON, the server won’t send messages back to your program throughout it’s execution so traffic is further reduced.
Tip 3 – Set the Initial Database Size Accordingly!
If you set it too small, as the database expands, the data file(s) will grow in size but not necessarily together. These files will become fragmented on the disk. This results in more disk operations, which unfortunately result in more CPU usage as well as more disk operations. Sizing it appropriately will prevent this fragmentation from occurring for the most part. If you feel that you databases are too fragmented you could rebuild the databases or detach them from the SQL Server engine and run a disk defrag on the disk where the database files are stored.
There is another aspect of this. Set the growth increments large enough. If the increments are too small you will create more fragmentation for the database.
Tip 4 – Use Indexes!
Use indexes where your “where” clauses point to. When indexes are not used the query has to scan every record in the table to find the results. If it is indexed, SQL Server scans through the index (containing just the field(s) that you need). Which results in less disk I/O and much faster results. Don’t do this on fields that are constantly written over because because writing to the field has two writes (one in the table and one in the index). Also constant changes can lead to index fragmentation, which will slow down queries where many rows are returned.
That’s it for now but more will be posted in the future. If you found this useful, please subscribe.
Problem
Here is something interesting I have run across. I sometimes write reports in an Access database. As soon as I transfer the report over to the client’s computer, the computer appears to lose its default printer settings.
Background
As it turns out, Access remembers your printer settings from the last time you ran the job. I have also found that if you have a different printer installed than where the report is going to be used, it will lose the settings. So if you need a certain behavior to occur like duplex printing do the following:
Solution
This will hopefully save you some time in you MS Access reporting.
Refactoring Self 