By default, the TableAdapter/Data Source drag-and-drop paradigm generates some fairly clumsy code to bind rowsets to the UI. As it is, the wizards (more like Dark Lords) encourage developers to select all columns from a base table with no WHERE clause. The developers is given no opportunity to do anything to limit the rows returned—not until they manually reconfigure the queries or use SPs using the TableAdapter designer. The wizards repeat the same table-based query for each table selected in the Data Source. If the developer blinks (does not know better or has watched one of the demos we’ve all seen) and chooses “Tables” in the initial dialogs, a ST TableAdapter is created for each and every table in the database which can add thousands of lines of useless code to the application. Microsoft needs to disable this option.

Continue reading "Visual Studio 2008 -- Still Has Not Addressed Basic Issues" »

Posted by William Vaughn at 06:01 PM | Permalink | Comments (1)

One of the "inside" aliases that I monitor posed the question: What should a (very) introductory Visual Basic .NET course (for college students) contain? At least one response went into some detail that (IMHO) missed what students getting started as programmers really need to know.
My answer:
____________________________________________________________________________________________
I might start (a very introductory course) in much the same way as I did when I taught CS101 to college students. Let’s assume, that these students know these foundational concepts—what’s a CPU, what’s RAM, disk, and the rest. Can we assume that these students are going to need know how to solve business problems with a computer program they have written themselves—as opposed to doing it with ledgers, 3x5 cards or Excel?

To do so they will need to know how to:
• Learn what needs to be done. This might mean interviewing customers those that will use the application and understanding the problem they are trying to solve. Too many developers come up with a solution to problems that don’t exist or don’t address the customer’s problems.
• Learn how to design before coding.

Continue reading "What Should a (Very) Introductory Visual Basic Course Contain?" »

Posted by William Vaughn at 12:03 PM | Permalink | Comments (2)

I got back from Vegas Thursday night--tired but it was worth it. I don't know if my new book Hitchhker's Guide to Visual Studio and SQL Server was the best seller, but it was close. They sold about 45 copies and I must have signed most of them. My hand is still sore. Thanks to each and every person that walked up to me to congratuate me on the new book or to tell me how much I had helped them over the years. It's ordinary people like this that keep me going. Of course, Vegas is "interesting" as well. It's not that often that I get to walk through a casino on the way to work. I did, however, trip over someone as I was gawking at a waitress...

Continue reading "Connections--A Great Conference" »

Posted by William Vaughn at 05:36 PM | Permalink | Comments (2)

A recent question on the newsgroups asked about the life-expectancy of DAO and if it makes sense to transition to ADO to access their database.

The problem here is not DAO or even ADO classic (COM-based ADO). The problem here is the JET engine.
When you write an application using JET whether you you Access or VB6 or VB.NET or any other language, you are limited by the capacity and architecture of the shared-file architecture of JET. Your security is limited by JET's inability to be encrypted and since by its very nature it's designed to be passed around as a file and accessed by whomever receives it, it should not contain private data. Sure, there are lots of situations where a DBMS as simple as JET is okay--as in the home or for some non-secure office applications. But IMHO, JET is really not suitable for businesses that need to pass manage secure data. We've talked about and debated the merits and foibles of JET for many years here on this newsgroup and in other forums.

Continue reading "Question of the Day: DAO to ADO to ADO.NET" »

Posted by William Vaughn at 08:39 AM | Permalink | Comments (0)

Another question came up in the newsgroups today that's been asked (and answered) before so to short-circuit having to repeat myself, here is a blocl of code that can be used to enumerate the providers on a system and the services that the provider can see on the network. In other words, it lists the SQL Server instances on the network and puts the list in a DataGridView.

This code is extracted from an example in my new book Hitchhiker's Guide to Visual Studio and SQL Server due to be on the streets in early November. See www.hitchhikerguides.net for more information.

Continue reading "Question of the Day: Enumerating SQL Server Instances" »

Posted by William Vaughn at 04:50 PM | Permalink | Comments (2)

I saw this question in the microsoft.public.vb.database newsgroup this morning and since I wanted to start a “question of the day” series of blog entries, I thought this was as good a candidate as any.
The question:
I am having some problems with Visual Basic 2005 Express Edition and databases. I have tried three different pieces of code (one I made that executes an INSERT command on a SQL database, another sample project from Microsoft also using SQL, and finally one from VB 2005 EE for Dummies using an Access database) on two different computers but none of the databases saved. I have never worked with databases before, but I followed all the instructions exactly for the samples I used. I could see the information was in the dataset when I ran one of the programs. It had multiple forms that displayed the information in the database in two different ways. When I modified the data in on form and clicked the save button and then went to the other form I could see the updated data. When I closed the forms and started the program all the changes were gone, however in the video that went along with the code I saw the code run just as it should, the data came back when he restarted the program. Am I missing something here? I don't see what I could have possibly done wrong. It does not make sense to me at all. HELP ME!!!,

Continue reading "Question of the Day: Data Disappears from new SQL Server Database" »

Posted by William Vaughn at 09:52 AM | Permalink | Comments (1)

I met with Microsoft last week over dim sun where we chatted about what’s right and what’s wrong with the documentation and help system. I said that the search engine is just busted. When I ask for an in-context topic I still get flooded with irrelevant topics. If I add more information to narrow the search, it seems to widen the search. I guess I’m just spoiled by Google that seems to get it right far more often.
So, I revert to the index trying to find something that’s close to what I want. This works better but still there are topics where the work selected takes me to Cleveland when I wanted Boston—and who would want Cleveland anyway?
When in the IDE, I make the mistake of selecting the term to search for—this works sometimes, but other times I just get “Form” or a suburb of Cleveland again.
After the talk, Microsoft wanted me to give them specific cases where I get sent off into the ozone. I’m building a log of all of these hits in an attempt to get them to see what’s going wrong.
Incidentally, they said that all of those little comments we put at the bottom of help topics are being kept by the Visual Studio people—and not passed to the help writers. Sigh.

If you have problems finding stuff with help in Visual Studio 2005, could you post these issues here? I expect that everyone is working with Visual Studio in ways that are far different than what I’m doing. Let’s see if we can help them help us (so to speak).
Bill

Posted by William Vaughn at 09:24 AM | Permalink | Comments (5)

Yet another question was posted in the public ADO.NET newsgroup and I decided to use this forum to answer this fairly common question: Are Stored Procedures (SPs) faster than ad-hoc queries? One misconception is that SPs are compiled into some binary-like code and simply loaded into memory on each invocation--kinda like a DLL. They aren't. In order to take advantage of the current data "statistics" (how the information is distributed in the tables being referenced), each query is recompiled (to some extent) at runtime.

No, not every statement is recompiled on each use. The mechanism works like this (somewhat simplified): When you execute a query (parameterized or not) it's syntax checked, compiled, placed into the common RAM cache and executed. The compiled query sits in the RAM cache until space is needed for something else. When you execute the same query (or one that's pretty close--perhaps with a different parameter value) there is no need to recompile the query--the cached query is simply rexecuted with the new values.

A stored procedure works the same way but the server can recognize it more quickly and knows if it has its query plan in cache--it does not have to be checked for correct syntax--that was done when it was first created. So, yes, there is a little performance benefit whenrunning a SP when compared to an ad-hoc query. While there is the additional (minor) benefit of the number of bytes sent to the system to execute the SP is far lower (just the string that has the name and parameter values)--this benefit is not that great.

Continue reading "Are Stored Procedures Faster than Ad-Hoc Queries?" »

Posted by William Vaughn at 10:23 AM | Permalink | Comments (0)

As I have talked about many times here, in newsgroups and in my sessions, books and articles, IMHO JET/Access is not suitable in a business application. I've detailed the problems that include its physical IO over the network (which makes it prone to data loss), its inability to be backed up while any application is still connected, its need to be periodically compressed, it's lack of scalability (which means you have to start over when the customer outgrows it), it's (very) limited capacity and the number of users it can support. It should never be used as a web host unless you don't mind terrible performance--that's because it's a "client" engine--not a service designed to support parallel operations. One of the most serious problems is its inability to encrypt data in place and its fragile security system. This makes it "officially" unsuitable to manage HIPA-compliant data. The fact that you access JET over a very problematic MDAC stack is and always has been another problem. Each time the stack is changed, your application might or might not work. Jet is also accessed over a COM-based OLE DB interface--in unmanaged code.

Continue reading "JET? Are developers still considering it?" »

Posted by William Vaughn at 09:43 AM | Permalink | Comments (0)