In SQL Server 2005 Standard Edition and up we had database mirroring which supported having a single mirror on site which was synchronous mirroring only with asynchronous mirroring being an Enterprise Edition feature.  I would like to see this same feature set moved into the SQL Server 2014 Standard Edition product as well.  How I would see this working would be the normal AlwaysOn Availability Group configuration that we have today but only supporting a single replica.  I can see synchronous data movement being the only data movement option which would allow for a local onsite HA without giving you the ability for geographically distributed disaster recovery as that requires asynchronous data movement.

If Microsoft wanted to do something really nice for their Standard Edition customers they could allow for a second replica which would be an Azure database replica and that would allow for Disaster Recovery within Standard Edition while pushing Azure (which we all know is a big deal for Microsoft these days).

So there you have it, that’s what I would like to see in the SQL Server 2014 Standard Edition version of the product.  Do I expect to see it, honestly I’m really not sure.  Microsoft has been very tight lipped about what is coming in the Standard Edition, mostly because these decisions haven’t been made yet.  Once they are someone people will be happy, others wont be, but that’ll be what we have to deal with until we do this all over again in a couple more years when the next version of SQL Server is released.

Denny

Overall the thought here is that the impact of this is probably pretty minimal. After all this is the same overhead for RCSI.  However where this becomes a problem is due to the page splitting that I mention in the other article and the fact that these 14 bytes don’t survive after an index rebuild but they do an index reorg.

I can see major page splitting issues happening on clustered indexes which are using the default fill factor of 100% full, which most clustered indexes use as that’s the correct fill factor to be using for a key column which is always growing.  But now as rows need to be changes within the clustered index that’s going to cause our clustered indexes, which never used to have to worry about page splits to suddenly start to split.

The solution here is that when using the readable secondary feature clustered indexes will need to account for this by using a fill factor other than 100% (or 0%) for the fill factor so that the page splits within the clustered index can be avoided.

Additionally we need to think long and hard about using index rebuilds or index reorgs when doing index maintenance.  If we have a table where the records are updated for a while then never updated again index rebuilds probably makes sense instead of index reorgs.  If however we are only doing index reorgs we are now storing an additional 14 bytes of data per row, eventually for most if not all of our rows for ever.  When talking about large tables that’s suddenly some actual space that needs to be accounted for.  For a table with 1 Billion rows that’s an additional 13 Gigs of additional space.  All in all not all that much space.  But if your 1 Billion row table has a row width of just 35 bytes your table should be about 33 Gigs, so an additional 13 Gigs of space is quite a lot.

I guess where I going here is that if you are going to be using AlwaysOn Availability Groups to protect your data and you are going to be using the readable secondary feature then there are going to be some other things within the database that you want to take into account.

To look at what’s going on lets create a sample new table in a table and take a peak at the data.  To setup this test we create a new database and setup that database for use with AlwaysOn Availability Groups.  The availability group is setup with no readable secondary replicas.

create table MyTest (c1 int identity(1,1),
c2 int,
c3 varchar(100))
GO
insert into MyTest
(c2, c3)
values
(1, ‘test’)
GO 400

This creates a new table in the database with 400 rows in it.  Looking at the output from DBCC IND we can see that this table takes up 2 data pages with a root page (this will become important later on).

Looking at the data for the first data page we can see the following information.

Slot 0 Offset 0×60 Length 23

Record Type = PRIMARY_RECORD        Record Attributes =  NULL_BITMAP VARIABLE_COLUMNS
Record Size = 23
Memory Dump @0x000000003CACA060

0000000000000000:   30000c00 01000000 01000000 03000001 00170074  0………………t
0000000000000014:   657374                                        est

Slot 0 Column 1 Offset 0×4 Length 4 Length (physical) 4

c1 = 1

Slot 0 Column 2 Offset 0×8 Length 4 Length (physical) 4

c2 = 1

Slot 0 Column 3 Offset 0×13 Length 4 Length (physical) 4

c3 = test

Slot 0 Offset 0×0 Length 0 Length (physical) 0

KeyHashValue = (8194443284a0)

When we update this row changing the value of c2 to equal 2 nothing really changes which we can see from DBCC PAGE again.

Slot 0 Offset 0×60 Length 23

Record Type = PRIMARY_RECORD        Record Attributes =  NULL_BITMAP VARIABLE_COLUMNS
Record Size = 23
Memory Dump @0x000000003EECA060

0000000000000000:   30000c00 01000000 02000000 03000001 00170074  0………………t
0000000000000014:   657374                                        est

Slot 0 Column 1 Offset 0×4 Length 4 Length (physical) 4

c1 = 1

Slot 0 Column 2 Offset 0×8 Length 4 Length (physical) 4

c2 = 2

Slot 0 Column 3 Offset 0×13 Length 4 Length (physical) 4

c3 = test

Slot 0 Offset 0×0 Length 0 Length (physical) 0

KeyHashValue = (8194443284a0)

Next I’ve changed the settings for the availability group to support readable secondary replicas.  Once that change has been made we change the value of c2 for the same row to equal the value of 3.  Again we can look at this with DBCC PAGE.

Slot 0 Offset 0x1d4e Length 37

Record Type = PRIMARY_RECORD        Record Attributes =  NULL_BITMAP VARIABLE_COLUMNS VERSIONING_INFO
Record Size = 37
Memory Dump @0x000000003AEEBD4E

0000000000000000:   70000c00 01000000 03000000 03000001 00170074  p………………t
0000000000000014:   65737400 00000000 0000000f 06000000 00        est…………..

Version Information =
Transaction Timestamp: 1551
Version Pointer: Null

Slot 0 Column 1 Offset 0×4 Length 4 Length (physical) 4

c1 = 1

Slot 0 Column 2 Offset 0×8 Length 4 Length (physical) 4

c2 = 3

Slot 0 Column 3 Offset 0×13 Length 4 Length (physical) 4

c3 = test

Slot 0 Offset 0×0 Length 0 Length (physical) 0

KeyHashValue = (8194443284a0)

Looking at these two outputs from DBCC PAGE we can see a couple of differences.  First we see an additional value in the “Record Attributes” field which adds in VERSIONING_INFO to the value.  We also see that the record size has changed from 32 to 37.  Additionally we see that the Version Information has been added.

Looking at the DBCC PAGE output on one of the replicas for the same page as before we see some different information.

Slot 0 Offset 0x1d4e Length 37

Record Type = PRIMARY_RECORD        Record Attributes =  NULL_BITMAP VARIABLE_COLUMNS VERSIONING_INFO
Record Size = 37
Memory Dump @0x000000003893BD4E

0000000000000000:   70000c00 01000000 03000000 03000001 00170074  p………………t
0000000000000014:   65737440 01000001 0000000f 06000000 00        est@………….

Version Information =
Transaction Timestamp: 1551
Version Pointer: (file 1 page 320 currentSlotId 0)

Slot 0 Column 1 Offset 0×4 Length 4 Length (physical) 4

c1 = 1

Slot 0 Column 2 Offset 0×8 Length 4 Length (physical) 4

c2 = 3

Slot 0 Column 3 Offset 0×13 Length 4 Length (physical) 4

c3 = test

Slot 0 Offset 0×0 Length 0 Length (physical) 0

KeyHashValue = (8194443284a0)

Specifically at this point we see that the Version Pointer now has a value in it. This tells us that the SQL Server has put a copy of the original page into the tempdb database so that we can read it.

A question comes up as to what happens to the page when this row information is added.  Specifically does the page split because of this additional 14 bytes of new data per row.  The answer to this question is “it depends”.  In my testing that I did when I updated a single row the page didn’t split, mostly this would be because there was some free space in the database page.  When I updated rows 2-40 and looked at DBCC IND I saw that in fact the page had split.

Looking at the values within the page there are now 159 rows in the page which was the original database page when there were 322 rows within the database page.  The remainder of the rows were copied into a new database page.

Now that we’ve identified that SQL Server is going to be page splitting older database pages, potentially like crazy what can we do about it?  The answer to that question is to just deal with it and to decrease the fill factor as needed so that page splits happen as little as possible.

To make matters worse when we rebuild the index on the table and look at the output from DBCC PAGE again we can see that the additional flag has been removed from row 1 (seen below).  This tells us that no only will this problem come up the first time that data is modified, it’ll come up every time that index rebuilds are done when the data is changed for the first time after the rebuild.

Slot 0 Offset 0×60 Length 23

Record Type = PRIMARY_RECORD        Record Attributes =  NULL_BITMAP VARIABLE_COLUMNS
Record Size = 23
Memory Dump @0x000000003E0CA060

0000000000000000:   30000c00 01000000 03000000 03000001 00170074  0………………t
0000000000000014:   657374                                        est

Slot 0 Column 1 Offset 0×4 Length 4 Length (physical) 4

c1 = 1

Slot 0 Column 2 Offset 0×8 Length 4 Length (physical) 4

c2 = 3

Slot 0 Column 3 Offset 0×13 Length 4 Length (physical) 4

c3 = test

Slot 0 Offset 0×0 Length 0 Length (physical) 0

KeyHashValue = (8194443284a0)

Changing the data again, this time changing the first 40 rows (id values 1-40) the new flag comes into place as expected.  If we reorganize the index instead of doing a rebuild this time the flags are left in place.

This tells us that the better option for doing index maintenance on databases which are being protected by AlwaysOn Availability Groups is going to be to use reorganize commands instead of rebuild commands.  This way the 14 byte pointer isn’t removed from the rows so that when they are modified the additional 14 bytes of data doesn’t need to be added.

If you’ve got rows which are changed all the time then this will be a way to handle it.  If the rows never change after the data is reorged then it may or may not be something worth worrying about.

Hopefully this helps answer the questions of what these extra bytes are for and how we can deal with them.

Denny

• EXECUTE, not required, but advisable.
• Windows Azure SQL Database and SQL Server — Performance and Scalability Compared and Contrasted
• Setting up Quorum Node Weight in a Windows Server Failover Cluster
• Central Subscriber Model Explained
• DBCC WRITEPAGE: an introduction

This weeks SQL Server person to follow on Twitter is: SaudiGeekNET also known as Hossam | حسام الفريح

Hopefully you find these articles as useful as I did.

Don’t forget to follow me on Twitter where my username is @mrdenny

.

Denny

The query that was having problems is a dynamically generated query which comes from a stored procedure.  The basic query which was being run looked a lot like this.

SELECT /*A bunch of columns*/
FROM answer a
JOIN session s ON a.SessionID = s.SessionID
WHERE a.SessionID IN (4857385,5269932,5682479,6095026)

Most of the time that this query was being run everything was just fine, however there were a some times when it was timing out. Looking into the execution plan for a normal run of the query everything looked just fine. However when this was being run sometimes there were 1.2M rows being pulled from the session table even though there were 4 specific IDs being passed in.

Looking at the properties of the index scan which was being performed against the session table I could see that the SQL Server turned the query to WHERE s.SessionID >= 4857385 AND s.SessionID <= 6095026. This was a problem as for some of these queries as like with this query there were 1.2M rows being returned from the session table instead of the 4 rows that should have been returned.

The fix in this case was to simply change there where clause from “WHERE a.SessionID” to “WHERE s.SessionID”. Now I’m not sure why this worked from the internals point of view but I do know that it worked. The next time the stored procedure ran it run in milliseconds instead of timing out at 30 seconds.

In this case the server in question was SQL Server 2008 R2 (10.50.2796). This may or may not apply to other builds of SQL Server. I’m pretty sure this is going to be a your mileage may vary sort of thing.

This is officially the least amount of work that I’ve ever done tuning a query as I only made a single change to a single letter of the query.

Denny

• Common Table Expressions (CTEs), Window Functions, and Views
• How big of a risk is BYOD?
• How can I get that user out of my table quickly
• Unemployed Chinese Graduates Say No Thanks To Factory Jobs
• Choosing the Right SQL Server Version: It’s Trickier than You’d Think

This weeks SQL Server person to follow on Twitter is: sqlpass also known as PASS

Hopefully you find these articles as useful as I did.

Don’t forget to follow me on Twitter where my username is @mrdenny

.

Denny

As a part of this configuration we wanted to do the DBCC CHECKDB as a part of the backup job so that after the DBCC CHECKDB is complete the databases will then be backed up.

The catch here is that we didn’t want to have to dig through the errorlog file to figure out what the database was that’s having the problem, and we didn’t want the job to fail if there was a problem so I started looking at catching errors when running DBCC CHECKDB.  Sadly there aren’t really any good ways to do this.  TRY/CATCH doesn’t work because DBCC doesn’t actually throw error messages like a normal SQL statement does.  It returns the errors, but it doesn’t actually throw the errors so the CATCH block isn’t actually captured.  Running DBCC CHECKDB within an EXEC sp_executesql doesn’t catch the error either for the same reason, the error isn’t thrown it is simply displayed.  (The reason that the errors from DBCC CHECKDB show up in Management Studio in red I would assume is because SSMS is catching the format and displaying it correctly.)

To catch the errors I had to resort to some old school “error handeling” using the @@ERROR system function.  While this isn’t perfect, I’m not looking for perfect here.  I’m just looking for something that says that there’s an error so that I can send an email when there is an error then continue to loop through the databases looking for others with problems.

As this is step 1 of a multistep job this step is configured to move on to the next step on success or failure (as an email will have been sent and the data logged to the ERRORLOG) then we’ll procede to the backups.

The code that I’m using looks something like this…

/*Populate the table #dbs with the databases that need to be checked.*/
DECLARE cur CURSOR FOR SELECT name from #dbs
OPEN cur
FETCH NEXT FROM cur INTO @name
WHILE @@FETCH_STATUS 0
BEGIN
SET @sql = 'DBCC CHECKDB ([' + @name + '])'
EXEC sp_executesql @sql
IF @@ERROR 0
BEGIN
set @subject = 'CHECKDB failure for ' + @name
set @body = 'DBCC CHECKDB failed for database ' + @name + '
Command run was: ' + @sql
exec msdb.dbo.sp_send_dbmail...
END
FETCH NEXT FROM cur INTO @name
END
CLOSE cur
DEALLOCATE cur

There’s some custom code at the top which figures out which databases to process so that the job step runs DBCC CHECKDB on the same databases which the job will backup (this is figured out based on the database size, if the database is online, and if the database is currently being bulk loaded).  This code isn’t shown as it’s not relivant to this specific problem.

Denny

All this sounds perfect (except for if I’m out of the country and I can’t get their text messages), except for one little issue.

Adding a new cell phone to send a text message to is as simple as just logging onto the bank’s webpage. Once I log into the site I can simply add another cell phone, verify that I have the cell phone via a text message and then I can use that cell phone to approve any wire transfers. All very convenient. The problem is that is someone else figures out my username and password for the website they to can add a cell phone to my bank account, approve it for use, then start sending wire transfers off all my money to their account.

So while Bank of America has two factor authentication, the second factor is dependent on knowing the first factor. For this to be actually useful two factor authentication it would need to require that I go into a branch with my ID to prove that I’m me and that I can add the phone as a two factor authentication phone. Additionally they should be using as an option one of the phone application based two factor authentication processes so that if I have several phones I can just use the one application, or if I’m not in the country I can still manage my money (which has been a problem a couple of times).

While I applaud the effort that Bank of America has put into having two factor authentication, doing it correctly would be a lot more useful.  As currently you have one factor authentication with an annoyance.

Denny

This precon is a full day session where we will be talking about all the security best practices.

Signing up for the precon is pretty simple, just do to the URL for the precon and fill out the form.

I hope to see you there,
Denny

Many people think that the simple recovery model doesn’t use the transaction log.  More specifically they think that it’s there because it has to be there, but that SQL Server doesn’t actually use it.  The reality is that SQL Server still uses the transaction log, much like it does in full or bulk logged recovery modes.  There are some transactions which are going to be minimally logged, but for the most part the INSERT, UPDATE and DELETE commands are going to be fully logged just like normal.

What SQL Server does with the transaction log in simple recovery model is that when the transactions are committed they are written to the transaction log and the pages are dirtied in the buffer pool.  When checkpoint runs the dirty pages in the buffer pool are written to the disk.  Everything up to this point is basically the same as with the other recovery models.  Once the checkpoint has been completed things get different between simple recovery and the other two recovery models.  With the simple recovery model the virtual log files which were just checkpointed and had their dirty pages written to disk will be marked as no longer in use (status=0).  With bulk logged and full recovery this doesn’t happen until the transaction log backup has been completed.

Hopefully this helps dispel the myth.

Denny

Aside from that we also chat a little bit about some of the issues that people are seeing when it comes to adopting SQL Server 2012 (hint, it’s mostly a money problem).

As always, thanks for listening and I hope you enjoy the show.

I hope you enjoy the session.

During the show this week we talk about some of the ups and downs of working from home and some of the tricks that we’ve learned over the years of working from home to keep yourself sane and keep being productive while working somewhere which is both distracting and isolating all that the same time.

You can find out more about grant on his blog “Home of the Scary DBA“.

Here are some write-ups of some of the data breaches which we talked about during the podcast.

Got Health Data? Your Penalty Exposures For Data Breaches Just Increased

Federal Department Bans Use of Portable Devices (YAFF)

Utah Health Department – Yet Another Flashdrive FAIL (YAFF)

BC Health Ministry Data Breach Affects Millions

Karen’s Data Modeling Blog at Datversity.net

Salary data

In this podcast we talk all about Direct Access and Remote Access, the overall differences between the two concepts and some of the stumbling blocks that people may run into when planning on deploying Direct Access on Windows Server 2008 R2 and Windows Server 2012.

It seems like the majority of health data breaches I read about are via insiders with access to patient information systems stealing and selling their data.

Federal authorities say Sergei Kusyakov, who was involved with Metro Chiropractic and Wellness Center and City Lights Medical Center, illegally obtained private information about patients through Dale Munroe II and his wife, Katrina Munroe, who worked at Florida Hospital’s Celebration campus.

Authorities said Dale Munroe accessed more than 763,000 records for patients treated at various Florida

…

Additional reading can be found at the original author’s post.

New submitter uCallHimDrJ0NES writes “Security researcher Mark Gamache has used Moxie Marlinspike’s Cloudcracker to derive hashes from captured NTLM handshakes, resulting in successful pass-the-hash attacks. It’s been going on for a long time, probably, but this is the first time a ‘white hat’ has researched and exposed the how-to details for us all to enjoy. ‘You might think that with all the papers and presentations, no one would be using NTLM…or, God forbid, LM. NTLMv2 has been around for quite some time. Surely, everyone is using it. Right? Wrong! According to the last data from the W3 Schools, 21% of computers are running XP, while NetMarketShare claims it is 39%. Unless someone has hardened these machines (no MS patches do this), these machines are sending LM and NTLM responses!’ Microsoft has posted a little guidance for those who need to turn off NTLM. Have fun explaining your new security project to your management, server admins!”

…

Additional reading can be found at the original author’s post.

vikingpower writes “As a previous Slashdot story already reported, Ruby on Rails was recently reported to suffer from a major SQL injection flaw. This has prompted the Dutch government to take the one and only national site for citizens’ digital identification offline (link in Dutch, Google translation to English). Here is the English-language placeholder page for the now-offline site. This means that 16 million Dutch citizens cannot authenticate themselves anymore with government instances, and that those same government instances can not communicate anything to those same citizens anymore.” Fixes were released, so it looks like it’s on their sysadmin team now.

…

Additional reading can be found at the original author’s post.

RI labor dept. warns of possible privacy breach.

I think about data encryption, physical access controls to servers and such on a regular basis. But there are all kinds of formats via which data gets stored or communicated.  The Rhode Island Department of Labor recently had a data breach involving their call center.  Customers were able to hear conversations on other calls.  The department estimates fewer than 700 pe

…

Additional reading can be found at the original author’s post.

Folks have cited the recent InformationWeek article on how South Carolina’s Department of Revenue was hacked because the SC state government basically said, “It’s the IRS’ fault for not telling us we should encrypt social security numbers.” I’m not going to touch that. It stands on its own for its foolishness. However, I did key in on how the hack happened and how the data was obtained. I found this bit to be particularly interesting:

“But with more work, by Sept. 12, 2012, the attacker had successfully located and begun copying 23 database backup files, containing 74.7 GB of data, to another directory. Soon, the attacker compressed the data into 15 zip files, transferred them to another server, sent the data to an external system — outside the state’s control — and deleted the zip files to help hide the data breach, according to Mandiant’s report.”

In other words, the attacker, once inside the trusted network, located the database backup files, zipped them up, and then copied them offsite. That’s how the data was lost. The database backups were attacked.

…

Additional reading can be found at the original author’s post.

concealment sends this quote from MIT’s Technology Review: “AT&T screwed up in 2010, serving up the e-mail addresses of over 110,000 of its iPad 3G customers online for anyone to find. But Andrew Auernheimer, an online activist who pointed out AT&T’s blunder to Gawker Media, which went on to publicize the breach of private information, is the one in federal court this week. Groups like the Electronic Frontier Foundation worry that should that charge succeed it will become easy to criminalize many online activities, including work by well-intentioned activists looking for leaks of private information or other online security holes. [Auernheimer's] case hasn’t received much attention so far, but should he be found guilty this week it will likely become well known, fast.”

Read more of this story at Slashdot.

Additional reading can be found at the original author’s post.

Instead you have to settle for ordering the book outright and having it shipped to you.  That’s right, no more being a pre-order book, it’s published and available to be shipped directly to you.  Currently Amazon is selling the book at full price which is $49.95, but if you have Amazon Prime it is available for Amazon Prime shipping.  Because it is considered to be a text book you get a $5 Amazon MP3 Credit (what ever terms and conditions that Amazon chooses do apply).

This is a totally updated edition of the book including all sorts of new information about security within SQL Server 2012.  I of course cover things like how to secure AlwaysOn Availability Groups, how to use user defined server roles, contained users, etc. I also dive into how to properly secure SQL Server Reporting Services and SQL Server Analysis Services so they can’t be used to access data that people shouldn’t have access to.

All in all this book is much larger with Amazon showing it at 408 pages compared to just 272 pages for the 1st edition.  If you find someone cheaper to purchase it make sure that you are in fact ordering the second edition.  The ISBN number is 1597499471.

I hope that you pick up a copy of the book and that it is useful for you in securing your SQL Server environment.

Denny

So if you’ve been waiting for the 2nd edition to come out, there’s no need to wait any longer.

If you want that physical book you can pre-order it, and hopefully it’ll be shipping within just a couple of weeks.  Amazon has August 15th listed on the US website, but I’m not sure if that is the actual date or not.

Denny

While a lot of the new information is focused on SQL Server 2012, there is also a lot of new material which relates to older version of SQL Server including chapters on SQL Server Analysis Services and SQL Server Reporting Services, information on Instant File Initialization, EXECUTE AS, Database Firewalls, SAN Security, Actual Data Security (no idea how this got missed the first time around, but that’s to Brent Ozar for pointing it out).

As far as the SQL Server 2012 information you’ll find updated information about the SHA2 hashing algorithms, Securing AlwaysOn Availability Groups, Security and SQL Server Clustering, Security and Contained Databases and a lot more.

If you already have a copy of the 1st edition I encourage you to take a look at the second edition as well.  I know that it’s really soon for a second edition of a book (the first edition just came out February 2011, but this new edition comes on the release of SQL Server 2012.

Hopefully you pre-order you copy today.

Denny

P.S. Yes this edition will be available for the Kindle as well, that takes a little time.  As soon as I know that it’s been posted for the Kindle (usually happens a little after Amazon gets the physical books) I’ll post another announcement here.

P.P.S. If you visit my SecuringSQLServer.com site I’ve updated everything there for the new edition.  You can always find the old edition listed on the Other Books page on that site or on the Books page on mrdenny.com.

There’s no easy way to fix the vulnerability of the database to this attack except to “harden” the database by applying all the patches and making all the security requirements consistent. Monitoring the database for unusual activity is important, too.

Patching SQL Server will NOT prevent SQL Injection attack, at all.  The SQL Server isn’t the attack vector for a SQL Injection attack, the web application is the attack vector.  By the time the SQL Injection attack gets to the SQL Server database (or any database) it’s too late.

SQL Injection is actually really easy to protect yourself from.  Simply stop using dynamically generated SQL  and instead start using parametrized queries (also called bound queries).  That’s it, that’s the big secret.  Yes I understand that writing your .NET code as parametrized queries is harder to write than just doing string concatenation and running the query, but getting your site attacked and putting malware on your customers computers because you didn’t want to do a little typing is just no excuse.

As this is a blog about my book “Securing SQL Server” here’s the sales pitch.  In the book I talk all about how to use parametrized queries.  It really isn’t that hard there is lots of sample code on how to do it.  You don’t need to use stored procedures to use parametrized queries.  You can do it with normal dynamic SQL as well, it works basically the same.

In case you didn’t get my point yet, parametrized queries are the ONLY WAY that you can 100% be sure that you are protecting yourself from SQL Injection attacks.  If you can’t find some links on how to use parametrized queries here are a few links for you PHP, .NET, and more .NET.

Denny