Whats the best route for learning DAO

Hi everyone,

Having never dabbled in DAO, I was wondering what the best (meaning quickest) way to pick it up.

Do i go for MSJet or ODBC, or are they both the one and same?

I'm really new to this....

DocZaf
{;->

Do you ever get the feeling you have two heads or something?
Well i do,

maybe The question is phrased correctly?

Suggestion 1 :

Go ODBC

Reason 1 :

Its supposed to be database independant which means you could hook it up to Access, SQL Server, Oracle or anything else and it would essentially remain the same.

Suggestion 2 :

Use MSDN, TechNet or VB Help Files

Reason 2 :

The best way of learning this is to go directly to your help files, have a look at the examples shown, copy them into a VB form (modify them to fit of course) and run them. Have a look at the Properties attached to the objects, the methods that can be used and heavily look at the "See Also" whenever you are in something.

Thanks Gen-X

I'd just about given up hope of getting any tips.

Cheers
Zaf
{;->

DAO is on it's way out...if you're going to learn something, study ADO (unless you are working on systems that are already using DAO).

A good place to start (for just about anything) is MSDN. Try this portion of their site for an ADO tutorial.

Also on MSDN are partial books on line. Beginning Visual Basic 6 Database Programming gets you going on ADO (just click the down arrow at the top of the document to move to the next chapter as you read).

Good luck,

~seaweed

Cheers to you also Seaweed,

My I'm lucky to have so many knowledgeable people helping me get my study off to a sooper dooper start.

Thanks to both you and Gen-X, i should be able to go on and learn it quickly, i just wanted to save time if that makes sense.

DocZaf
{;->

Doctor Zaf!

Finally, I get to give my input to you. I started using DAO 3 three years ago while I was learning Access95. If you ever get stuck, go into Access95 and look up the help on DAO. It is very useful. Don't use the new MSDN because it just flood you with information which you don't know what to take in.

Seaweed is right, DAO is going out and ADO is the way to go.


Here are some good ACCESS site which evolves around DAO.
http://home.clara.net/tkwickenden/
http://www.codeguru.com/vb/Tutorials/more3.shtml
http://www.microsoft.com/accessdev/

I will send you a sample of DAO usage in Access97. You can converted to Access2000. I commented very thoroughly which makes it so easy to understand. Even a baboon smoking a cigar can understand it - Not that I am refering to you as the baboon.

Actually Seaweed...

If you want to be totally honest even ADO is on its way out ;-)

Its to be replaced with OLEDB but all of this would confuse people if they knew the number of different connection methods to databases let alone pound them with acronyms ;)

Okay, This is what i reckon,

I'm not a certified programmer, but i have an excellent sense of logic, and pick up quick, what i dont want to do is to learn some technology and just be at the fine tuning stage when it becomes obselete, so which way do i go?

Thanks again
DocZaf
{;->

ps
Whats the cheapest car on the road?


A stolen one!

There are approximately 6 methods to connect to the database right now.

Data Environment
ADO Control
ADO Codes

RDO Codes
DAO Control
DAO Codes

The last three are going obsolete soon. The first three is the most updated one.

Zaf my Man....

Your statement of not being a certified program shows in your reluctance to start using something that will very soon be obsolete...

:D

Welcome to the world of programming!!!!
Where the things you use today are obsolete by tomorrow!!!!

Sorry to rain on your parade but this industry is changing so rapidly it isn't possible to find something that will be around in a years time. I remember using DAO when it first came out and then using ADO when it first came out, ODBC when it was first born and now OLEDB.

The best you can do is learn the principles behind things and then just adapt to the current "flavour of the month".

I would stick with ADO at the moment.. it will be around for a while mainly because existing programs will be using it and its a good starting point if any though slightly more confusing than say DAO in the initial stages of learning

Okay, thats great, so ADO it is, and whats more is that its comforting to know that you all agree on that. so that gives me more confidence...

Zaf Khan
Cheers all, and thanx for the sample code Nitro
{;->

Don't forget to check out the VB World Database Tutorial right here. I think that there are 7 installments now and it gives a pretty good quick overview of stuff.

Actually, guys, ADO is mainly based on OLEDB.
For example there are 2 ways to get a recordset from the Command (stored procedure):
ODBC way and OLEDB way. Here is an example. Lets say I have this Stored Procedure:

Code:

---

Create Procedure sp_MyProc
@CustomerId int
    Begin
        Select * from Customers Where CustomerId = @CustomerId
    End

---

Here are 2 ways you can get the recordset based on this Stored Procedure. Let's say I have a Textbox which will hold the CustomerId, which we will pass:

ODBC way:

Code:

---

Dim cn As New ADODB.Connection
Dim rs As New ADODB.Recordset
Dim strSQL As String

cn.Open "DSN=MyDSN"

strSQL = "{ call sp_MyProc (" & Val(Text1.Text) & ")}"
Set rs = cn.Execute strSQL

'Recordset now hold data based on the stored procedure

---

OLEDB way:

Code:

---

    Dim cn As New ADODB.Connection
    Dim cm As New ADODB.Command
    Dim rs As New ADODB.Recordset

    cn.Open "DSN=MyDSN"

    With cm
        Set .ActiveConnection = cn
        .CommandText = "sp_MyProc"
        .CommandType = adCmdStoredProc
        .Parameters.Append .CreateParameter("CustomerId", adInteger, adParamInput, , Val(Text1.Text))
        Set rs = .Execute
    End With
    'Recordset now hold data based on the stored procedure

---

That's it.

Great, I thnik I now have enoughto make a start, I just have to dig up some free time to do the study bit.

Cheers again
DocZaf
{;->