When saving a boolean value to a Microsoft® SQL Server 2000 database. In SQL Server 2000, boolean values are represented as data type "bit", with valid values of numeric 0 or 1. When building a SQL INSERT or UPDATE statement, we need to convert a value of TRUE or FALSE easily to a 1 or 0 respectively.
I have found the easiest way is to use the IIF command. Depending on your coding preferences, you should find one of the two choices below will work well for you:
Dim MySQLBoolean as string = IIF(MyBoolean, "1", "0")
or
Dim MySQLBoolean as integer = IIF(MyBoolean, 1, 0)
Compared to an IF-THEN-ELSE approach, I like the IIF approach since it delivers the desired result in a single line of code.Readabilityy in code is very important, but with all other things being equal, one line of code is generally more readable than five lines of code.
Joe Kunk
Friday, July 22, 2005
Thursday, July 14, 2005
The Power of Panels in ASP.NET
It is fairly common that it takes several pages to be presented to the user to complete a single logical task within a web application.
Say you have a collection of free email newsletters that you want to offer to your site visitors. If a visitor clicks on the link to select one or more newsletters, you may well present:
[Screen 1] a checklist of the newsletters to choose from with a Submit button, then
[Screen 2] a list of just the newsletters selected with a confirmation button, then
[Screen 3] a printer friendly listing of the selected newsletters along with information on how to change or cancel subscriptions and a nice thank you for subscribing to your site newsletters.
Prior to ASP.NET, you likely would have written these as three separate ASP pages; Screen 1 posts to Screen 2 which posts to Screen 3. Easy enough, but it certainly cluttered up the folders on your web server and tracking logic errors was more difficult across three separate source files.
Now with ASP.Net, all three screens can easily be coded into individual panel objects, all within the same .ASPX web page. The code-behind file makes the needed panel visible and sets the visibility of the other panels to false. The user still sees three different screens in sequence but coding is greatly simplified since it is all contained within a single .vb or .cs code-behind file.
I have used this technique in several web applications and it works great. The invisible panels are not included in the final page to the browser so the download times remain tight. I hope you find this tip very useful.
Joe Kunk
Say you have a collection of free email newsletters that you want to offer to your site visitors. If a visitor clicks on the link to select one or more newsletters, you may well present:
[Screen 1] a checklist of the newsletters to choose from with a Submit button, then
[Screen 2] a list of just the newsletters selected with a confirmation button, then
[Screen 3] a printer friendly listing of the selected newsletters along with information on how to change or cancel subscriptions and a nice thank you for subscribing to your site newsletters.
Prior to ASP.NET, you likely would have written these as three separate ASP pages; Screen 1 posts to Screen 2 which posts to Screen 3. Easy enough, but it certainly cluttered up the folders on your web server and tracking logic errors was more difficult across three separate source files.
Now with ASP.Net, all three screens can easily be coded into individual panel objects, all within the same .ASPX web page. The code-behind file makes the needed panel visible and sets the visibility of the other panels to false. The user still sees three different screens in sequence but coding is greatly simplified since it is all contained within a single .vb or .cs code-behind file.
I have used this technique in several web applications and it works great. The invisible panels are not included in the final page to the browser so the download times remain tight. I hope you find this tip very useful.
Joe Kunk
Tuesday, July 12, 2005
VB.Net Modules in ASP.NET - Trick or Treat in July
Here is the story of a feature in VB.Net that is at the same time very useful and potentially very dangerous.
Microsoft carried the construct of a Module forward from Visual Basic 6 into VB.Net (reluctantly as I understand it). A popular feature among VB6 programmers, it can be viewed as a global class available to all other forms and classes. VB6 programmers commonly used it to hold global variables and methods that would be needed by multiple forms. No instantiation needed, it was just there and global. Very convenient.
VB6 was used primarily to write single-user desktop windows applications. Yes, with the proper level of skill and prayer it could be used for more advanced purposes, but it truly shined as a way to quickly deliver high-quality desktop applications. In a single user environment, a shared global module is not a problem. Use of a module in a single user VB.Net application is still not a problem for the same reason.
Now consider the impact of a module in an ASP.Net application running on a IIS web server. Herein lies the power and the danger.
First the danger. Like before, a module is a class that automatically global to the entire application without requiring any instantiation. But now that single application is being used simultaneously by potentially hundreds or thousands of users. See the problem yet? Any variable declared at the module level is single-instance shared global among all users. If you casually define a module level variable of 'UserName' and base your security permissions on that, you will experience tremendous security issues as incoming users take on whatever security permissions were enabled by the last client that set the 'UserName' variable. Ouch!
Now the power. Modules are a great way to share single-instance methods for very efficient memory usage in VB.Net web applications. Only one copy of each module method is loaded in memory for all users of the application. As long as each of these modules are designed with shared usage in mind and do not depend on any static variables or try to maintain state across calls, this can be a very powerful and efficient design strategy.
Conclusion: In VB.Net web applications, use module level variables with great care, or not at all if possible. Use module methods with care to ensure that they can be safely shared.
I hope you find this information helpful. I wish I had known it earlier and saved myself some grief. Your comments are welcome.
Disclaimer: This post is based on some painful lessons learned from personal experience and not the result the detailed research on the topic. All of the statements in this post are correct to the best of my knowledge but please verify any use of this information with sufficient testing in your particular environment.
Joe Kunk
Microsoft carried the construct of a Module forward from Visual Basic 6 into VB.Net (reluctantly as I understand it). A popular feature among VB6 programmers, it can be viewed as a global class available to all other forms and classes. VB6 programmers commonly used it to hold global variables and methods that would be needed by multiple forms. No instantiation needed, it was just there and global. Very convenient.
VB6 was used primarily to write single-user desktop windows applications. Yes, with the proper level of skill and prayer it could be used for more advanced purposes, but it truly shined as a way to quickly deliver high-quality desktop applications. In a single user environment, a shared global module is not a problem. Use of a module in a single user VB.Net application is still not a problem for the same reason.
Now consider the impact of a module in an ASP.Net application running on a IIS web server. Herein lies the power and the danger.
First the danger. Like before, a module is a class that automatically global to the entire application without requiring any instantiation. But now that single application is being used simultaneously by potentially hundreds or thousands of users. See the problem yet? Any variable declared at the module level is single-instance shared global among all users. If you casually define a module level variable of 'UserName' and base your security permissions on that, you will experience tremendous security issues as incoming users take on whatever security permissions were enabled by the last client that set the 'UserName' variable. Ouch!
Now the power. Modules are a great way to share single-instance methods for very efficient memory usage in VB.Net web applications. Only one copy of each module method is loaded in memory for all users of the application. As long as each of these modules are designed with shared usage in mind and do not depend on any static variables or try to maintain state across calls, this can be a very powerful and efficient design strategy.
Conclusion: In VB.Net web applications, use module level variables with great care, or not at all if possible. Use module methods with care to ensure that they can be safely shared.
I hope you find this information helpful. I wish I had known it earlier and saved myself some grief. Your comments are welcome.
Disclaimer: This post is based on some painful lessons learned from personal experience and not the result the detailed research on the topic. All of the statements in this post are correct to the best of my knowledge but please verify any use of this information with sufficient testing in your particular environment.
Joe Kunk
C#.Net versus VB.Net
This is one of the first issues a developer will face when making the commitment to begin working with the .Net platform. Which to use as your primary development language?
There may be external factors that will push you toward one choice over the other, such as standards in your workplace, a large legacy codebase of C++ or VB, or even the personal preference of your mentor. Since the .Net framework is shared by all .Net languages, it is essentially a toss-up. There are functional differences between the two languages, but they are minor. The good news is that the consistent .Net framework method names between both languages makes it relatively easy for a VB.Net programmer to read C# code, and for a C# programmer to read VB.Net code.
I prefer to work in VB.Net, simply because I have worked in Visual Basic for years and am very comfortable with that style of coding. That said, I can work in C# with only slightly more effort and I think you would find the same to be true. I have seen several surveys over the last year on this issue and developers are pretty evenly split among the two, with professional developers slightly in favor of C#, probably due to the strong presence of C++ code in commercial software applications.
If you have the freedom to make this choice yourself, then choose the language that you are most comfortable in and know that you are in good company with either choice. Learning to be productive in .Net application development is challenging enough, there is no need to complicate it with unnecessary worry about which language to work in.
Joe Kunk
There may be external factors that will push you toward one choice over the other, such as standards in your workplace, a large legacy codebase of C++ or VB, or even the personal preference of your mentor. Since the .Net framework is shared by all .Net languages, it is essentially a toss-up. There are functional differences between the two languages, but they are minor. The good news is that the consistent .Net framework method names between both languages makes it relatively easy for a VB.Net programmer to read C# code, and for a C# programmer to read VB.Net code.
I prefer to work in VB.Net, simply because I have worked in Visual Basic for years and am very comfortable with that style of coding. That said, I can work in C# with only slightly more effort and I think you would find the same to be true. I have seen several surveys over the last year on this issue and developers are pretty evenly split among the two, with professional developers slightly in favor of C#, probably due to the strong presence of C++ code in commercial software applications.
If you have the freedom to make this choice yourself, then choose the language that you are most comfortable in and know that you are in good company with either choice. Learning to be productive in .Net application development is challenging enough, there is no need to complicate it with unnecessary worry about which language to work in.
Joe Kunk
Monday, July 11, 2005
Welcome to JBK.Net
The goal of this BLOG is to share my experiences as a professional application developer and as a board member for our local .Net developer user group.
I have been programming since 1978 and have watched application development evolve from very humble beginnings to the depth & breadth of what Microsoft's .Net environment has to offer today. There is intense joy and pride in delivering an elegant application to the user and knowing that it is among the best software available anywhere for that purpose. I felt that joy with my first program in 1978 and I still enjoy that feeling every time I deliver a new application. That feeling, at least in part, is what drives me to be the best programmer that I can be, and continue to strive to deliver an ever more exciting application next time.
I firmly believe that the .Net platform is the most productive application development platform available today. By taking advantage of its rich framework, I can create applications in a reasonable timeframe that I would never have even attempted before. It has expanded my horizons as a developer immensely. It is an exciting time in the application development world.
By sharing my experiences with .Net, both good and bad, I hope to help others become more productive and effective with .Net.
I will share my mistakes so that others can avoid them. I will share my questions when I am struggling, so we can learn together. I will share my successes so that others can add to their knowledge and skills. Like most developers, what I don't know about .Net far exceeds what I know. I expect to learn a lot from the feedback and comments of the readers of this blog and I truly look forward to the dialog.
Welcome to JBK.Net. I appreciate your company and companionship on the shared quest to become skilled and productive .Net developers.
Joe Kunk
The goal of this BLOG is to share my experiences as a professional application developer and as a board member for our local .Net developer user group.
I have been programming since 1978 and have watched application development evolve from very humble beginnings to the depth & breadth of what Microsoft's .Net environment has to offer today. There is intense joy and pride in delivering an elegant application to the user and knowing that it is among the best software available anywhere for that purpose. I felt that joy with my first program in 1978 and I still enjoy that feeling every time I deliver a new application. That feeling, at least in part, is what drives me to be the best programmer that I can be, and continue to strive to deliver an ever more exciting application next time.
I firmly believe that the .Net platform is the most productive application development platform available today. By taking advantage of its rich framework, I can create applications in a reasonable timeframe that I would never have even attempted before. It has expanded my horizons as a developer immensely. It is an exciting time in the application development world.
By sharing my experiences with .Net, both good and bad, I hope to help others become more productive and effective with .Net.
I will share my mistakes so that others can avoid them. I will share my questions when I am struggling, so we can learn together. I will share my successes so that others can add to their knowledge and skills. Like most developers, what I don't know about .Net far exceeds what I know. I expect to learn a lot from the feedback and comments of the readers of this blog and I truly look forward to the dialog.
Welcome to JBK.Net. I appreciate your company and companionship on the shared quest to become skilled and productive .Net developers.
Joe Kunk
Subscribe to:
Posts (Atom)