I recently had occasion to access the contents of a cookie stored on the clients computer using Javascript. I found the following javascript function very handy. I wander if something similar is built into javascript:
function getCookie(name) {
var dc = document.cookie;
var prefix = name + "=";
var begin = dc.indexOf("; " + prefix);
if (begin == -1) {
begin = dc.indexOf(prefix);
if (begin != 0) return null;
} else {
begin += 2;
}
var end = document.cookie.indexOf(";", begin);
if (end == -1) {
end = dc.length;
}
return unescape(dc.substring(begin + prefix.length, end));
}
Monday, July 30, 2007
Stylesheet Link
Probably the easiest method of adding a link to an additional style sheet in code is this:
Page.Header.Controls.Add(new StylesheetLink("/css/mystyle.css"));
Page.Header.Controls.Add(new StylesheetLink("/css/mystyle.css"));
Thursday, July 26, 2007
A Look at GUIDs
Summary:
Not many people enjoy using Globally Unique Identifiers (GUIDs), partly because they are cumbersome to type and work with for humans. However they fill a need and can provide some interesting benefits. SQL Server expert Andy Warren takes us through what a GUID is and how you can use it easily in your code.
Not many people enjoy using Globally Unique Identifiers (GUIDs), partly because they are cumbersome to type and work with for humans. However they fill a need and can provide some interesting benefits. SQL Server expert Andy Warren takes us through what a GUID is and how you can use it easily in your code.
The difference between Where and Group By
"The WHERE clause (# 3) evaluates data before the GROUP BY clause does. When you want to limit data after it's grouped, use HAVING. Often, the result will be the same whether you use WHERE or HAVING, but it's important to remember that the clauses are not interchangeable. Here's a good guideline to follow when you're in doubt: Use WHERE to filter records; use HAVING to filter groups.
Usually, you'll use HAVING to evaluate a group using an aggregate. For instance, the following statement returns a unique list of ZIP codes, but the list might not include every ZIP code in the underlying data source: SELECT ZIP, Count(ZIP) AS CustomersByZIP FROM Customers GROUP BY ZIP HAVING Count(ZIP) = 1
Only those groups with just one customer make it to the results. "
Usually, you'll use HAVING to evaluate a group using an aggregate. For instance, the following statement returns a unique list of ZIP codes, but the list might not include every ZIP code in the underlying data source: SELECT ZIP, Count(ZIP) AS CustomersByZIP FROM Customers GROUP BY ZIP HAVING Count(ZIP) = 1
Only those groups with just one customer make it to the results. "
What Query Plans are in SQL Server's Memory?
"SQL Server memory is primarily used to store data (buffer) and query plans (procedure cache). In this article I'll show how much memory is allocated to the procedure cache (RAM). I'll explain how to determine what plans are in the cache and how often they're used.
SQL Server stores the procedure cache in 8KB data pages. You can use the dynamic management view sys.dm_os_memory_cache_counters to provide a summary of how the cache is allocated using this query"
SELECT TOP 6
LEFT([name], 20) as [name],
LEFT([type], 20) as [type],
[single_pages_kb] + [multi_pages_kb] AS cache_kb,
[entries_count]
FROM sys.dm_os_memory_cache_counters
Order By single_pages_kb + multi_pages_kb DESC
SQL Server stores the procedure cache in 8KB data pages. You can use the dynamic management view sys.dm_os_memory_cache_counters to provide a summary of how the cache is allocated using this query"
SELECT TOP 6
LEFT([name], 20) as [name],
LEFT([type], 20) as [type],
[single_pages_kb] + [multi_pages_kb] AS cache_kb,
[entries_count]
FROM sys.dm_os_memory_cache_counters
Order By single_pages_kb + multi_pages_kb DESC
What Data is in SQL Server's Memory?
"SQL Server memory is primarily used to store data (buffer) and query plans (cache). In this article I'll show how much memory is allocated to the data buffer (or RAM). I'll explain how to determine what tables and indexes are in the buffer memory of your server.
SQL Server stores its data in 8KB data pages. As these pages are read off disk they are stored in memory. This is referred to as buffer memory. A list of all the data pages in memory is stored in the dynamic management view sys.dm_os_buffer_descriptors."
SQL Server stores its data in 8KB data pages. As these pages are read off disk they are stored in memory. This is referred to as buffer memory. A list of all the data pages in memory is stored in the dynamic management view sys.dm_os_buffer_descriptors."
Wednesday, July 25, 2007
Some Tips and Tricks for using an ObjectDataSource with a Gridview
using sp_executesql
use Northwind
go
declare @RECCNT int
declare @ORDID varchar(10)
declare @CMD Nvarchar(100)
set @ORDID = 10436
SET @CMD = 'SELECT @RECORDCNT=count(*) from [Orders]' +
' where OrderId < @ORDERID' print @CMD exec sp_executesql @CMD, N'@RECORDCNT int out, @ORDERID int', @RECCNT out, @ORDID print 'The number of records that have an OrderId' + ' greater than ' + @ORDID + ' is ' + cast(@RECCNT as char(5))
The name 'Session' does not exist in the current context
Tuesday, July 24, 2007
SQL Case - Syntax error converting the varchar value
variable order by when mixing datatypes? [Archive] - dBforum...
An excerpt from the above link that helped me figure out a problem I was having when using a case statement to compare strings and ints and was getting unexpected results:
" In T-SQL, a CASE expression has its data type determined before the query is processed, and the type of the CASE expression is the lowest precedence type that is at least as high a precedence of each of the CASE alternatives. This means that a CASE expression with both varchar and int alternatives will be typed as int. The result of this is that whenever any of the alternatives is evaluated, it will be interpreted as an int, which in the case of a non-numeric varchar string, can cause a run-time error. If the value of a parameter is such that the non-numeric varchar is never accessed, this won't cause an error. You might think it would be better if the CASE expression weren't typed, but that would leave undetermined the question of how something like MAX(CASE when ColumnA = 0 then ColumnB else ColumnC end) should be evaluated. There is another alternative to handle this, and that is to cause the CASE expression to be of type sql_variant (needs SQL Server 2000), to which any numeric or varchar value can be cast, and which will preserve the correct ordering of each column according to its base type: "
An excerpt from the above link that helped me figure out a problem I was having when using a case statement to compare strings and ints and was getting unexpected results:
" In T-SQL, a CASE expression has its data type determined before the query is processed, and the type of the CASE expression is the lowest precedence type that is at least as high a precedence of each of the CASE alternatives. This means that a CASE expression with both varchar and int alternatives will be typed as int. The result of this is that whenever any of the alternatives is evaluated, it will be interpreted as an int, which in the case of a non-numeric varchar string, can cause a run-time error. If the value of a parameter is such that the non-numeric varchar is never accessed, this won't cause an error. You might think it would be better if the CASE expression weren't typed, but that would leave undetermined the question of how something like MAX(CASE when ColumnA = 0 then ColumnB else ColumnC end) should be evaluated. There is another alternative to handle this, and that is to cause the CASE expression to be of type sql_variant (needs SQL Server 2000), to which any numeric or varchar value can be cast, and which will preserve the correct ordering of each column according to its base type: "
GridView and the ObjectDataSource
Wednesday, July 18, 2007
Temporarily Changing sa password
Tuesday, July 17, 2007
T-SQL Temporary Tables vs. Table variables
1. There is no universal rule of when and where to use temporary tables or table variables. Try them both and experiment.
2. In your tests, verify both sides of the spectrum – small amount/number of records and the huge data sets.
3. Be careful with migrating to SQL 2005 when you use complicated logic in your stored procedures. The same code can run 10-100 times slower on SQL server 2005!
DataTable.Select problem, not finding rows
uniqueid clientid not evaluating
HtmlLink for javascript in head tag using jsLink
Subscribe to:
Posts (Atom)