In Windows Vista the default value for the Persist Security Info parameter of an ADO connection string has changed from True to False.

You should be aware of this because it can prevent your legacy code from working properly under Windows Vista. If its value is set to False the Server, Database, Trusted_Connection and Password parameters will be removed from the ConnectionString property of the Connection object once the connection has been opened. If you’re creating new connections by just copying the ConnectionString property from an existing and already opened connection to the new one, your code will break under Vista.

The problem can easily be fixed by explicitly setting Persist Security Info to True in your original connection string but it should be mentioned that this can be a potential security risk if untrusted code gets access to your Connection object. Even more so in case you’re not using integrated security and the connection string actually contains the user’s password for accessing the database. It’s a much better practice to have the actual connection string stored separately and use it directly to create new connections.

On a side note, SqlClient in ADO.NET works much more consistently. The Persist Security Info parameter always defaults to False. It also only removes the Password parameter from the ConnectionString property which makes changing its value to True completely unnecessary unless you really feel a strong urge to share your user’s password.

Although in Visual Basic 6 all string variables are inherently Unicode, the same is not true for the components that come with it – they aren’t capable of displaying (or accepting input of, for that matter) Unicode characters. The same goes for most of the popular third party ActiveX controls that are available on the market.

Unless you’re deciding to move the form (or even the complete application) to .NET, the best solution is to use the components from the Microsoft Forms 2.0 Object Library. There are a few downsides though:

• They come with Microsoft Office and aren’t freely redistributable. But even if your clients don’t have Microsoft Office, they can legally obtain the components by installing the free Microsoft ActiveX Control Pad which contains them.
• The use of these components outside Microsoft Office isn’t officially supported. Still this shouldn’t be a problem as long as everything works. After all, even Microsoft recommends using these components in such a situation.
• The set of the components is not really complete and it might not be enough if you have a bit more complex needs. In this case there’s still UniToolbox available. I haven’t tried it but it looks a promising collection of Unicode components for Visual Basic 6. Might be worth a look.