Managing Picasa's database

Picasa 3 uses a large data stored in user data on the primary windows partition.
This is sort of stupid since I installed picasa onto a 1TB drive to store photos yet the index stays on C:\ eating valuable disk space.  Plus its to the size on my C:\ drive where I can no longer defrag it.

Here is a solution to the problem, using Windows XP symbolic links and a tool called Junction from the SysInternals group at Microsoft.

Dear Google:

   Please pay attention to your products.  Storing a large database in User data in Windows is bad form and a mis-use of local application data. THIS IS NOT WHAT MICROSOFT MEANT USER DATA FOR.

Please note, I install SQL server and the databases are not stored as entries in user data \ local application data
because IT IS A DATABASE!

Any way, now that my rant is out of the way here is the good stuff...


Move Picasa Database to Another Location:

'via Blog this'

Uses Junction:

Chinthaka's Blog Page: ContextSwitchDeadlock was detected

Chinthaka's Blog Page: ContextSwitchDeadlock was detected: "ContextSwitchDeadlock was detected"

'via Blog this'

Steps to disble this exception in VS 2008.

I was getting this error running some long queries.


ContextSwitchDeadlock was detected
Message: The CLR has been unable to transition from COM context 0x3361c50 to COM context 0x3361dc0 for 60 seconds. The thread that owns the destination context/apartment is most likely either doing a non pumping wait or processing a very long running operation without pumping Windows messages. This situation generally has a negative performance impact and may even lead to the application becoming non responsive or memory usage accumulating continually over time. To avoid this problem, all single threaded apartment (STA) threads should use pumping wait primitives (such as CoWaitForMultipleHandles) and routinely pump messages during long running operations.

Making good use of SQL 2005/2008 Rank() function

Ran into the age old problem of migrating data from one system into a new system  where new system requires a unique row id but the previous system does not.  In the scerario,  I am moving 400,000 records across a linked server from SQL 2000 to SQL 2005/2008.  Generating a rowID per row is expense in any type of cursor or While Loop for 1/2 million records.  Using the 2005/2008 Rank() function I managed to migrate 400,000 records in under 3 minutes with the linked server connection running over internet through my home cable modem connection.  Not too bad at all.

SELECT rank() OVER (ORDER BY fPat.PatientID, fMrn.MRN) as RowID

FROM [FRIS].FRIS_DB.[dbo].tbPatients fPat                 

INNER JOIN MRIS.[dbo].W_PATIENT mPat ON mPat.Pat_Id = fPat.PatientID

INNER JOIN [FRIS].FRIS_DB.[dbo].tbMRN fMrn ON fMrn.PatientID = fPat.PatientID