I teach VB until recently VB6, now we have VB.NET installed in my teaching room.
Many early teaching tasks are little different from VB 6 - some things are easier for example students no longer need to remember when to use .caption and when to use .text.

My question is my students need to pass an examination where they need to remember how to code.

In ADODB they can write:
<code>Dim myConn = New System.Data.Odbc.OdbcConnection("DSN=VBVetsDSN") </code>
in OLEDB
<code>Dim myConn = New OleDbConnection("Provider=Microsoft.Jet.OLEDB.4.0; Data Source=C:\myDatabase.mdb;")</code> Question: is there an easier way?
Setting up the ADODB DSN name is easy as they just follow the prompts. Am I worrying too much that they will never remember the "provider string"? Unless they get that right how can they test a program and get the marks for testing?

Question for anybody who has already had this problem - what was the easiest way for them to use database in .net?

Previously using VB6 even the weakest students could create a basic database program using ADODC control, data report, and data environment.

Many want to be programmers but few actually make it, but no reason for them all not to get the experience of programming and a pass grade for their unit!

We have a tutorial on OleDb Basics in VB.Net that you could have them look over, this might help them with some of the questions they have about interacting with the OleDb class in VB.Net, also we have one on SQL Basics in VB.Net for those who prefer the MSSQL flavor of database.

Hope this helps

I have just created my first database within VB express 2008 using the tools provided within the IDE. I had a basic database up and running within the hour. That includes the tables etc. I started off with the intension of doing it the easy way just to get me going and then proceed onto more advanced Hard programming of which there are plenty of Tutorials and code snippets available here at DIC. However I was fairly impressed with the way everything worked within the IDE, creating SQL queries, tables e.t.c that I stuck with it and I soon had a really good database application.

So really I think .net will give you the ease of use yet you can take it to what ever level you want. Dont forget also that VB express is free to down load from microsoft so you students can practice at home.


Here is a link that I use

http://msdn2.microsoft.com/en-us/vbasic/bb466226.aspx

Happy coding

The easiest is way for them is to never even type a connect string. Use the server explorer, use it to navigate to the resource you want. Always use OleDb, there's never reason to choose anything else. Even in your example, forget Odbc, it's been marginalized by OleDb for years.

In their project, create an empty DataSet. Take the objects from server explorer that you're interested in and drop them into the DataSet in designer. Show them the code that's been magically created and discuss namespaces.

If you really want to do it manually, like for the test, point out the the properties of the connection show the connection string and how to cut and paste that.

Hope this helps.

Thank you I will use the tutorials.

Hi I am seeing that what you say is true from my research.
With DSN ODBC the dataset location is external to the program. In all the examples I have read (MS Books and others) actual database locations are used.
This worries me, not for my immediate needs but I have become used (over decades of programming in assembler/cobol/C/ even VB) of NOT using actual file/database locations in code am I missing something?

its called moving with the times which can only be good for for your students.

When it comes to client / server, you have to explicitly set up your connection somewhere. It's simply no optional. There exist numerous ways of making this as secure as possible. Also, modular enough that's it's not hard coded.

Locations are often stored in external config files. This works well if the user must enter their login info. However, it's not real good if you need to store username and password, because then anyone can read the config for them.

Web applications are idea for the practice of keeping volatile information, like locations and logins, out of compiled code. That information is still stored in external config files, but those files are stored on a server and inaccessible to the user.

The next tier out would be keeping a data layer in a web service. The client would preform all transaction through the external service and authenticate once against that. The service itself holds the most sensitive keys.

From back in cobol days, you're really only dealing with one box, even if it feeds numerous terminals. Most modern systems have at least one other server involved, sometimes more. The application simply must know how to get there at the beginning.

Hope this helps.