Access 2000 to 2003

[travismp]

I have 5 databases running 100% in Access 2000. We are switching to Office 2003 within a couple weeks via an upgrade. What should I do to prep my databases for the switch?

Is there any upconverting tool I need to do ect? Thanks.

 

[rainman89]

dont think so. you should be fine!

 

[boblarson]

Actually, sorry to correct you Ray (I know how you hate it when I do this ) but when going from 2000 to 2003, you should be aware that if you use any ADO references, DAO is now back to the default in 2003. So, it shouldn't really affect any existing databases since the ADO reference will have been set, but hopefully you are fully qualifying your code anyway (Dim rs As ADODB.Recordset instead of rs As Recordset).

Just something to be aware of when creating new databases in 2003, since you'll be used to 2000, is that the default for a new DB in 2003 has BOTH DAO and ADO checked in the references. So, you will definitely want to fully qualify your code for the correct object type, even on the DAO side.

 

[rainman89]

Actually, sorry to correct you Ray (I know how you hate it when I do this ) but when going from 2000 to 2003, you should be aware that if you use any ADO references, DAO is now back to the default in 2003. So, it shouldn't really affect any existing databases since the ADO reference will have been set, but hopefully you are fully qualifying your code anyway (Dim rs As ADODB.Recordset instead of rs As Recordset).

Just something to be aware of when creating new databases in 2003, since you'll be used to 2000, is that the default for a new DB in 2003 has BOTH DAO and ADO checked in the references. So, you will definitely want to fully qualify your code for the correct object type, even on the DAO side.

Don't hate it at all (i hate being wrong). You teach me tons, forgot about ADO references... doh!

 

[Daveyk01]

Actually, sorry to correct you Ray (I know how you hate it when I do this ) but when going from 2000 to 2003, you should be aware that if you use any ADO references, DAO is now back to the default in 2003. So, it shouldn't really affect any existing databases since the ADO reference will have been set, but hopefully you are fully qualifying your code anyway (Dim rs As ADODB.Recordset instead of rs As Recordset).

Just something to be aware of when creating new databases in 2003, since you'll be used to 2000, is that the default for a new DB in 2003 has BOTH DAO and ADO checked in the references. So, you will definitely want to fully qualify your code for the correct object type, even on the DAO side.

Hello Bob. I use Access 2000 exclusively as we do not have Access 2003. I always open tables like this:


dim rs as recordset
dim db as database
dim strSQL as string
'
strSQL = "Select *.........
set db = currentdb()
set rs = db.OpenRecordset(strSQL, dbOpenDynaset)

Is that a bad/archaic method based on what you said above? For future compatabilites, should that first line be: Dim RS as ADODB.Recordset? Is there anyother changes necassary>

I know nothing of ADO or DAO other than they are three letter acronyms. I know the methods that I know how to use work. I don't always know why they work <grin> - that's scarey!! heh heh

Thanks

 

[Daveyk01]

Actually, sorry to correct you Ray (I know how you hate it when I do this ) but when going from 2000 to 2003, you should be aware that if you use any ADO references, DAO is now back to the default in 2003. So, it shouldn't really affect any existing databases since the ADO reference will have been set, but hopefully you are fully qualifying your code anyway (Dim rs As ADODB.Recordset instead of rs As Recordset).

Just something to be aware of when creating new databases in 2003, since you'll be used to 2000, is that the default for a new DB in 2003 has BOTH DAO and ADO checked in the references. So, you will definitely want to fully qualify your code for the correct object type, even on the DAO side.

Hello Bob. I use Access 2000 exclusively as we do not have Access 2003. I always open tables like this:


dim rs as recordset
dim db as database
dim strSQL as string
'
strSQL = "Select *.........
set db = currentdb()
set rs = db.OpenRecordset(strSQL, dbOpenDynaset)

Is that a bad/archaic method based on what you said above? For future compatabilites, should that first line be: Dim RS as ADODB.Recordset? Is there anyother changes necassary?

I know nothing of ADO or DAO other than they are three letter acronyms. I know the methods that I know how to use work. I don't always know why they work <grin> - that's scarey!! heh heh

Thanks

 

[boblarson]

Hello Bob. I use Access 2000 exclusively as we do not have Access 2003. I always open tables like this:


dim rs as recordset
dim db as database
dim strSQL as string
'
strSQL = "Select *.........
set db = currentdb()
set rs = db.OpenRecordset(strSQL, dbOpenDynaset)

Is that a bad/archaic method based on what you said above? For future compatabilites, should that first line be: Dim RS as ADODB.Recordset? Is there anyother changes necassary?

I know nothing of ADO or DAO other than they are three letter acronyms. I know the methods that I know how to use work. I don't always know why they work <grin> - that's scarey!! heh heh

Thanks

The code you show is DAO and, to be really safe and clear, it should read

Dim db As DAO.Database
Dim rs As DAO.Recordset

In Access 2000, you may have just the DAO reference set and not an ADO reference, so it works for you. However, in 2003 the default is that both are checked so leaving off the explicit reference in the code can cause problems.

 

[Banana]

***Dirty Hack! Do not use it as a permanent solution! BAD! BAD! ***

If you are strapped for time, and your database has ridiculous amount of lines of code, and need to upgrade to 2003 right away, there's two ways to get it working right away

1) When you open the database in 2003, go to VBE and clear any references to ADO. That will work if you never use ADO anywhere in your code.

2) You could just ensure that DAO has higher priority than ADO. This means any implicit references will be resolved by DAO before ADO (actually, ADO will never get a chance, IINM).

But this should be strictly a stopgap solution. You still do need disambiguate references as Bob showed you how to. The above solution, while easy to implement, is not foolproof.

***Dirty Hack! Fix it right away! BAD! BAD! Friggin' dirty hack are Satan's spawn!***

 

[Daveyk01]

What is DAO verses ADO and why does it matter what method a "dim rs as recordset" causes to happen?

Still learning..... thanks.

 

[boblarson]

What is DAO verses ADO and why does it matter what method a "dim rs as recordset" causes to happen?

Still learning..... thanks.

Pat Hartman has a short, but good, explanation here:
http://www.access-programmers.co.uk/forums/showpost.php?p=455820&postcount=3

And the "why does it matter..." is because if you don't, you can get compile, or runtime, errors because Access does not like ambiguity.