I would still look at it just to make sure. The error is what happens when attempting to access a 64bit SharePoint from 32bit code. I know the language. I've read a book. - _Madmatt

Unless it uses the OleDb provider, each database needs its own provider -- but the "install" is just a copy of the DLL: Ca.Ingres.Client.dll FirebirdSql.Data.FirebirdClient.dll InterSystems.Data.CacheClient.dll MySql.Data.dll Oracle.DataAccess.dll

That is what I was looking for... Thanks

Wow thanks alot. I found this web site which shows that you can have a condition where if the build is set to a certain type then you can include or exclude references. Then in the build I can define something like UsingThirdPartyControls and in my code I can place #if UsingThirdPartyControls #endif. I think this could work. Thanks alot. Chris

If you want to know if you can spread a large projects compile over multiple machines to speed it up there's 3rd party software to do so. IIRC the one I've heard of before is called incredibuild. Otherwise [Microsoft is] toast in the long term no matter how much money they've got. They would be already if the Linux community didn't have it's head so firmly up it's own command line buffer that it looks like taking 15 years to find the desktop. -- Matthew Faithfull

Well, given that definition, you only have two choices... 1. Use application settings, but have a different section for each application user 2. Create your own setting schema and implement that schema from scratch. As far as I know, you cannot change the user settings file to apply to your application user... it always uses the windows user. I would recommend the first option as it is easier (IMO), and simply log a different section for each user in the app settings. Hope this helps, Sounds like somebody's got a case of the Mondays -Jeff

In addition to what has already been stated, security is another reason to use stored procs over in-line SQL. Unless you have strong, bullet-proof validation, using in-line SQL opens your app to SQL injection attacks. Stored procs can also be secured at the server so if your app uses Windows authentication to grant access to SQL Server a user who is not authorized won't be able to run the proc, even if not using Windows authentication, different users, or groups of users can be secured. only two letters away from being an asset

For actual security you would need a password to be entered on application startup allowing you to use the System.Security.Cryptography namespace's cryptography classes. Need a C# Consultant? I'm available. Happiness in intelligent people is the rarest thing I know. -- Ernest Hemingway

Have a look at the following MS VS2005 Code Snippets[^] You will pretty much find a snippet in this collection for all your needs.

I dont want it to show up in bold.

Thanks for the input.

Hello, As snorki said befor Invalidate requires DoEvents, to have an emidiate reaction. But DoEvents is not a nice solution as it runs the whole message loop again. I would prefere the Refresh() method. All the best, Martin

Yes, you are right. Operators are overloaded. This is a special form of overloading, though, as operators are overloaded on a global level, not within the same class. I didn't really realise that distinction until now. :) --- single minded; short sighted; long gone;

maybe something like tibet from www.technicalpursuit.com. or maybe one of those OS sites like gh.os.t or bobel or something like that.