Access95 ->Access2000 DAO???

[aegon2002]

Hello,

I'm trying to convert an access95 application to Access2000(A2k). According to the whitepaper from microsoft A2k uses only DAO3.60. My access95 application uses Dao3.0.
Before converting I have to set the Access95 reference to DAO 360. But....my application won't compile. It does not know rs.update ("This argument is not optional&quot. I declared an rs as recordset and I tried dim rs as dao.recordset. No Nothing... When I return the reference to 3.0 all compiles quite well.
I don't know why this happens and I don't know how to solve it. Who knows???

I tried to solve it to just convert the 95 application by opening it within A2k. When I convert I get compilation errors. Just removing , updating and adding some references solves the compilation errors. However I lost some code!!!

strSQL = "[VERZ_NAAM] LIKE '" & UCase(strNaam) & "*' OR [VERZ_NAAM] LIKE '" & LCase(strNaam) & "*'"

has changed to:

strSQL = "[VERZ_NAAM]='" & strNaam & "'"

How could this happen and what's the problem, but more important how can I solve it???

Greetz,
Marcel

 

[cheerio]

Access 2000 has two methods of manipulating data from code. These are DAO and ADO. The newer ADO takes precedence and has some similar objects.

So instead of

Dim rst as Recordset

you need

Dim rst as DAO.Recordset

otherwise Access 2000 assumes you meant

Dim rst as ADO.Recordset

Similarly for other DAO objects such as database, querydef etc.

You might be able to fudge things by changing the order of the references in Tools/References so that DAO comes first. However, in the long run you are better to make your code unambiguous.

The prefix of DAO. can be added before you migrate if you wish.

Ken

 

[aegon2002]

I removed the reference to ado. Therefore A2k only knows DAO and it should not go wrong. I also said explicitely in code that the recordset is a dao recordset. It didn't help.
I asked two questions:
1. why does dao3.6 not recognize rs.update in my code
2. why is some code removed while converting 95 -> 2000
Maybe it has nothing to do with DAO ????

 

[cheerio]

ok sounds like it's not a DAO versus ADO problem.

I have successfully migrated from Access 97 to Access 2000 so the good news is that there should be no fundamental problem.

Another serious possibility is that Access and Excel code editors have been known to corrupt code. What happens is that whenever you edit some of the old code gets left behind in the file but is hidden from view. The editor does not compact the code but simply marks it as redundant. This is not cleared by compacting the database. Occasionally, bits of that old code can get reactivated giving strange results. In particular, it can be compiled even though it is invisible. The conversion to access 2000 may trigger problems that were previously dormant.

What you may have to do is:

copy code out to a txt or bas file to preserve it.
drop the module altogether
recreate the module
reimport the code from the txt file

In the case of a form you drop the code by opening in design view and setting the HasModule property to No.

You would need to do this in the Access 97 original database.

If you ever have similar problems in Excel there is a code cleaner utility available but I do not think it exists for Access. You can track it down by a search on the author in Google (Rob Bovey is the name).

Ken

 

[Rolliee]

aegon2002,

I found this and was able to 'work around' with a horrible solution but it works. Use as a recordset as long as you need the 'helps' that are provided and change 'recordset' to 'object' at compile.

Rollie