As I've mentioned before in prior posts, I recently bought a Dell XPS 9000 desktop running Windows 7 Ultimate 64-bit for my new development machine. I was previously using XP Pro SP3 running on an older Gateway machine (no, I'm not into building my own machines ). My move to Windows 7 64-bit is now complete and, all in all, it wasn't too bad considering that I had to move over 16+ development environments, including some like Delphi 5 that are over a decade old.

The most problematic issues were:

• Delphi 2007 and 2009 Debugger Issues under 64-Bit Windows
  
  Olaf Monien's blog post describes the issues and fixes:
  
  Delphi 2009 / Windows 7 / 64 bit Debugger Crash Workaround


Apart from those issues, however, the Delphi IDE's work exceptionally well under 64-bit Windows 7. Even older IDE's like Delphi 5, 6, and 7 work great.


• Visual Studio 2008 Server Explorer Issue
  
  This isn't really an issue with Visual Studio, but rather a self-induced problem caused by the fact that I last set up my development machine about 5 years ago. The basic issue is that we keep the ElevateDB product source code on a network drive, and the ElevateDB .NET Data Provider assemblies (a runtime assembly and a Visual Studio integration assembly) are also built in the same location. This is not normally an issue for normal DLLs and EXEs, but .NET has specific zone security settings that control the locations that assemblies can be loaded from. Network drives qualify as an Intranet location and, therefore, default to using Medium Trust settings under .NET. Because the ElevateDB .NET Data Provider assemblies require Full Trust, this restriction would cause Server Explorer to throw a very unhelpful "type initialization" exception when it tried to load our Visual Studio integration assembly during connection setup or activation. The confusion was exacerbated by the fact that normal Visual Studio applications that used the runtime ElevateDB assembly worked fine in the IDE, even in the debugger. I still don't know what the exact reason is for why the Visual Studio IDE obeys the zone security set in the .NET 2.0+ Framework configuration (C:\Windows\Microsoft.NET\Framework\v2.0.50727\CONFIG), but normal applications do not. If anyone has the answer on this, please feel to comment.
  
  One other thing to note: on 64-bit Windows, the default installation of the .NET 2.0+ Framework configuration tools are 64-bit only. If you need to configure the .NET 2.0+ Framework for 32-bit assemblies, you need to make sure to download and install the 32-bit .NET 2.0 32-bit SDK. You can tell the two apart by the fact that the 64-bit SDK is marked with the (x64) designation.



• Miscellaneous Applications
  
  Is it just me, or is it a bit disturbing that companies still distribute installation programs that require you to specifically run them as Administrator, as opposed to just having the installation program prompt the user to enter in the Administrator credentials to complete the installation ? Furthermore, these companies stick this information somewhere in the installation notes and don't make it readily apparent that this is a crucial requirement prior to installation. So, you end up with the installation failing, or the installation completing properly but the application not working because the installation didn't install everything or was subject to Vista or higher folder virtualization of the Program Files folder. Please don't get me wrong - we had similar issues when Vista first came out. However, after the first incident report of such an issue, the problem was corrected. So, the issue isn't that the problem occurs with older applications, it's that the problem occurs with new applications several years after the first Vista machines shipped.

Using Triggers to Correct Migration Issues

Here's a neat tip that deals with a question that is asked every now and then. Sometimes developers migrating to ElevateDB find that their source databases contain issues that prevent the automatic migrators from being used, and thus requiring manual transfer of the rows from the source databases to the target databases. One of these issues is tables containing primary key columns with NULLs which, under the SQL standard, is not permitted. Here's an example of an INSERT ERROR trigger that will trap such an exception, correct the problem by populating the primary key column with a default value, and then retry the INSERT operation:

CREATE TRIGGER "InsertError" ERROR INSERT ON "customer"
BEGIN
   -- Check for constraint error (1004) and test to see
   -- if the primary key column CustID (VARCHAR) is blank
   IF ERRORCODE()=1004 AND NEWROW.CustID IS NULL THEN
      SET NEWROW.CustID='';
      RETRY;
   ELSE
      RAISE;
   END IF;
END

Just create such triggers before transferring the rows, and then drop them afterwards.

---

Tags: Casual Friday

Permanent Link

Comments (1)	You must be logged in to comment
Bruno Krayenbuhl said...	Reply
>to specifically run them as Administrator On XP you can right click the installation .EXE  do Execute as... then continue installation and you are prompted with  Select a user ... Doesn't it work on Vista and later ?