Edwin Daniel's profileMicrosoft technologies a...BlogLists Tools Help

Blog


    July 31

    Dynamic port detection

    As a follow-up on my blog entry yesterday, I was doing more research on SQL Server port usage when I chanced upon this Microsoft KB. SQL Server clients use DBNETLIB to perform port detection.  This is either thru ODBC or SQLOLEDB componentes which loads DBNETLIB.  SQL Server clients can use the Client Network Utility for dynamic port detection.  This is to make sure that in case SQL Server uses a different port number during service startup or is configured to user dynamic port assignments, the client can map to the port number that a specific instance uses. Now, what if the client is a third party application running on a non-Microsoft platform(like a JSP application running on top of Apache on a Linux box?)  How does this port resolution work?
    July 30

    What? I lost my port on a named instance?

    One thing I realized is that SQL Server port numbers will not be the same for I don't know what reason.  I found this out while rebuilding a SQL Server named instance. We had standard settings in setting up SQL Server. But since I am rebuilding my test environment, I just used the default port number settings (which is 1433) during the process. To my surprise, it was using port number 3080 when the service started. Apparently, SQL Server dynamically determines the port it listens on. It will try to listen on the port it used previously. If for some reason it cannot bind to that port, the named instance may bind to a different port - which is obviously the case for my setup. Now this would cause a lot of problems if your SQL Server is interacting with a lot of servers, services and applications as you need to either change the port number to it's original value (which I think would be more appropriate) or change the clients to use the new port number. I have yet to dig up more details on this as to why SQL Server behaves that way. At least I know another place to look at when troubleshooting connectivity problems
    July 27

    The Pains of Collation Settings

    Collation settings define the physical storage of character strings in SQL Server. It specifies the bit patterns that represent each character and the rules by which characters are sorted and compared. Collation settings have a direct impact on the databases if you configure them to use a different collation other than the default. When you configure a different collation setting during the installation, the rest of the databases (system and user-defined) will have this setting was their default when you create them unless you specifically defined something different from the default. One case I encountered was that the tempdb database had a different collation setting compared to the user databases. This is because SQL Server was reinstalled and the master and msdb databases were restored from backup together with the user-defined databases. This made the collation settings of the entire database server back to their original configuration - well, almost. Since the model database was not restored (and obviously, the tempdb database does not require a backup), collation settings for the both would be the settings defined during re-installation. A script executed in one of the user-databases would require the use of the tempdb and since they do not have the same collation settings, queries will fail unless the queries themselves take into account collation setting differences. The next best bet is to rebuild the master database and change the collation settings and go through all the grueling task of restoring the system databases, provided that the user-defined databases are still intact. Well, another approach would be to simply restore the model database if you have a backup (or simply look for the old MDF and LDF files if they are still working fine). This is because tempdb database takes the settings of the model database everytime SQL Server service starts.  This will resolve collation problems should you encounter a similar case  
    July 26

    When backups can't be restored

    We always think that having a backup is more than enough to keep us afloat during a disaster. I always say that any backup will be useless unless it is tested.  I came across one case where a SQL Server 2000 backup for the master database cannot be restored because it was generated using a different patch set for SQL Server 2000. The backups were generated before applying SQL Server 2000 hotfix 2191.  After the patches were applied, a restore was attempted but failed.  An error was encountered which specifies that the backup was generated by an earlier version of SQL Server. A best practice approach is to generate backups before and after a patch will be applied. This makes sure that you have valid backups in case something happened.  It may be a bit costly as far as disk space is concerned but it sure beats not having a valid backup. It may even save you from spending sleepless nights trying to rollback to the patchset which generated the backups.   
    July 25

    Importing Word and Excel as InfoPath 2007 Forms

    If you have been working with business forms, you probably have created a few in either Microsoft Word or Excel.  One thing to make managing business forms a lot easy is to upload them in your Sharepoint portal.  This makes it easy to have a standardized form easily available to the rest of the organization. You can also port them over as InfoPath forms. In Sharepoint 2007, you have the option to use Forms Services instead of individual forms.  This makes it easy for users to have a unified and standardized format plus the advantage of binding the form to a backend database for data collection. If you have existing Word or Excel forms, you can easily import and convert them in InfoPath. Just run the Import Form Wizard in InfoPath to convert your existing Word and Excel forms to InfoPath forms - no need to re-create those forms.  For more information, check out the Introduction to importing and exporting form data and form templates
     

    Security Configuration Manager for Windows Mobile

    I was preparing my demos using .NET Compact Framework 3.5 and Visual Studio Orcas. I was using 2 devices for testing - an O2 XDA II mini running Windows Mobile 2003 and an O2 Atom Life running Windows Mobile 6 which I upgraded from v5.  I created a very simple PocketPC 2003 project in Visual Studio Orcas - a form with UI like buttons and drop-down lists. Deployment was straight forward in Windows Mobile 2003. So I ported the same project to a Windows Mobile 6 Professional project. Upon deployment on the O2 Atom Life, I get this error:
     
     Installation error. Stop all applications and processes,
    maximize available storage space, and run installation again. Support info: 4
    What I thought was a simple project turned out to be a nightmare. I checked the program Files folder and found out that my application was deployed as I see my EXE file. So I decided to run the EXE file and I got this error.

    An unexpected error has ocurred in app.exe. Select Quit and
    then restart this program, or select Details for more information.

    This application requires a newer version of the .NET Compact
    Framework than the version installed on this device

    I checked the Microsoft.NET CF 3.5.LOG file and it looks like I have deployed the .NET Compact Framework 3.5 properly. I was beginning to think that the device has something to do with it as I tried using a Dopod PDA phone and didn't have any problems. I suspect this has something to do with the device security. Upon persistent inquiry (thanks to the guys from Microsoft APAC and Singapore),  I was led to do two things - either sign the cab with a test certificate which ships with Visual Studio Orcas and the Windows Mobile SDK using the cabsigntool.exe or disable the device security. Option 1 is not a choice for developers as you will be doing this on a regular basis - creating projects, deploying the projects on the device for testing, etc. Besides, you don't want to be doing this every time you come up with a new project or re-deploy a modified project. So option 2 looks like a preferred choice. In order to disable the device security, you need the Security Configuration Manager tool for Windows Mobile. In Visual Studio Orcas, this is already available. You can check the security level of your device and can be used to turn it off (only possible with Pocket PC - Windows Mobile 6 Professional and Windows Mobile 5 PocketPC). I managed to turn off my device's security and deployment worked like a charm.  For more information on these, you can check out the following websites

     

    http://blogs.msdn.com/windowsmobile/archive/2007/04/25/security-configuration-manager-powertoy-an-orcas-feature.aspx

    http://blogs.msdn.com/hegenderfer/archive/2007/05/23/a-windows-mobile-security-primer-for-developers.aspx

    http://msdn2.microsoft.com/en-us/library/bb278115.aspx