|
-
Apr 14th, 2000, 07:34 AM
#1
Thread Starter
Fanatic Member
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
{;->
-
Apr 16th, 2000, 07:03 AM
#2
Thread Starter
Fanatic Member
Do you ever get the feeling you have two heads or something?
Well i do,
maybe The question is phrased correctly?
-
Apr 16th, 2000, 08:31 AM
#3
Hyperactive Member
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.
-
Apr 16th, 2000, 11:35 AM
#4
Thread Starter
Fanatic Member
Thanks Gen-X
I'd just about given up hope of getting any tips.
Cheers
Zaf
{;->
-
Apr 16th, 2000, 02:24 PM
#5
Frenzied Member
I agree with Gen-x
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
-
Apr 17th, 2000, 07:37 AM
#6
Thread Starter
Fanatic Member
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
{;->
-
Apr 17th, 2000, 07:57 AM
#7
Fanatic Member
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.
Chemically Formulated As:
Dr. Nitro
-
Apr 17th, 2000, 07:58 AM
#8
Hyperactive Member
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
-
Apr 17th, 2000, 08:08 AM
#9
Thread Starter
Fanatic Member
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!
-
Apr 17th, 2000, 08:22 AM
#10
Fanatic Member
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.
Chemically Formulated As:
Dr. Nitro
-
Apr 17th, 2000, 08:23 AM
#11
Hyperactive Member
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...

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
-
Apr 17th, 2000, 08:28 AM
#12
Thread Starter
Fanatic Member
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
{;->
-
Apr 17th, 2000, 09:46 AM
#13
Addicted Member
My 2 Cents
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.
-
Apr 17th, 2000, 10:53 AM
#14
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.
-
Apr 18th, 2000, 04:26 AM
#15
Thread Starter
Fanatic Member
Thanks to all {;->
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
{;->
Posting Permissions
- You may not post new threads
- You may not post replies
- You may not post attachments
- You may not edit your posts
-
Forum Rules
|
Click Here to Expand Forum to Full Width
|