Johnnycat1
Programmer
Does anyone know how to open an Access 2000 file with access 97???
Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations SkipVought on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Opening Access 2000 files with Access 97
- Thread starter Johnnycat1
- Start date
- Status
earthandfire
Programmer
BNPMike, what do you mean by If you have an mde file you don't don't need Access at all ?
I think you at least need the runtime for mde...if not the full version, and either way, you'd need that to be of the correct version.
I abhor and never use .mde's so I'm no expert, but it's my understanding that they're just an mdb without the design button (in a simplistic view).
--Jim
I abhor and never use .mde's so I'm no expert, but it's my understanding that they're just an mdb without the design button (in a simplistic view).
--Jim
earthandfire
Programmer
jsteph, they are more than that.
Modules are precompiled and as you say the design buttons are absent, which gives a degree of security in the frontend. I use them quite extensively and have found them slightly more stable than their .mdb counterparts.
Additionally, because the code is precompiled they compact to about two thirds (and sometimes less) then their compacted .mdb equivalent.
Modules are precompiled and as you say the design buttons are absent, which gives a degree of security in the frontend. I use them quite extensively and have found them slightly more stable than their .mdb counterparts.
Additionally, because the code is precompiled they compact to about two thirds (and sometimes less) then their compacted .mdb equivalent.
I will agree with earthandfire 
Mde gives you better stability as the code is compiled and encrypted. There is less chance of corruption plus the mde files doesn't bloat as much as the mdb file.
But you definitely need Access (full or runtime) to run any kind of Access database
Cheers!
ÙÇãá
It's important to learn the rules so that you know how to break them.
Mde gives you better stability as the code is compiled and encrypted. There is less chance of corruption plus the mde files doesn't bloat as much as the mdb file.
But you definitely need Access (full or runtime) to run any kind of Access database
Cheers!
ÙÇãá
It's important to learn the rules so that you know how to break them.
I would assume from the poster's question that he has Access 97 and wants to open an Access 2000 file. Jim's suggestion works if he has Access 2000, which he doesn't. I'm not sure there's a way for an older version of Access to open a database designed in a newer version.
Leslie
Leslie
Anything worth doing is a lot more difficult than it's worth - Unknown Induhvidual
Leslie
Leslie
Anything worth doing is a lot more difficult than it's worth - Unknown Induhvidual
Agif,
I'm aware of the other benefits of mde's, but from a practical standpoint they never had a place for what our shop needed--but this is all personal opinion, if anyone cares to read further, I'll explain.
If we needed both Access and good security (well, good for Access anyway), I used jet security, since you'd have to set that up anyway if you were doing an mde and you wanted to secure what I consider more important--the data. Mde's dont secure data, at least not in A97 or 2000. And in the real world I've found that most people (and don't take this the wrong way) do mde's because Jet is to much a hassle for the small project size, and apparently, so is disabling the shift key (even though there are ways around that), so the data is there for the taking. I don't care if you steal my code, but my companies data--I'd like to keep that secure.
And the biggest pain is that you can't debug on-the-spot when there are problems. And let's all be mortals here and agree that there will be problems, and they may be machine-specific. And it's a huge help to be able to debug on that users machine.
You can say what you want about 'best practices' and how testing/debugging should be done in the lab and before rollout, blah, blah, blah, but for those who say that--well, I live in the real world and really--if you want to be that serious about all that you shouldn't be using Access in the first place.
So the other mentioned mde advantages--file size and peformance...please. This is Access for gosh sakes. I'm not going fret over a few nanoseconds because some p-code is precompiled. Who cares. And file size--how much code are we talking about? A few hundred K? Cmon. 200 gig disks for $89, 100mbit ethernet is the standard. What's a few hundred K when the data is usually the bigger disk hog anyway.
I've just had too many support headaches where we have a machine-specific problem with a legacy mde and nobody knows which is the 'real' source .mdb.
But as I said--it's just my opinion, I could be wrong.
--Jim
I'm aware of the other benefits of mde's, but from a practical standpoint they never had a place for what our shop needed--but this is all personal opinion, if anyone cares to read further, I'll explain.
If we needed both Access and good security (well, good for Access anyway), I used jet security, since you'd have to set that up anyway if you were doing an mde and you wanted to secure what I consider more important--the data. Mde's dont secure data, at least not in A97 or 2000. And in the real world I've found that most people (and don't take this the wrong way) do mde's because Jet is to much a hassle for the small project size, and apparently, so is disabling the shift key (even though there are ways around that), so the data is there for the taking. I don't care if you steal my code, but my companies data--I'd like to keep that secure.
And the biggest pain is that you can't debug on-the-spot when there are problems. And let's all be mortals here and agree that there will be problems, and they may be machine-specific. And it's a huge help to be able to debug on that users machine.
You can say what you want about 'best practices' and how testing/debugging should be done in the lab and before rollout, blah, blah, blah, but for those who say that--well, I live in the real world and really--if you want to be that serious about all that you shouldn't be using Access in the first place.
So the other mentioned mde advantages--file size and peformance...please. This is Access for gosh sakes. I'm not going fret over a few nanoseconds because some p-code is precompiled. Who cares. And file size--how much code are we talking about? A few hundred K? Cmon. 200 gig disks for $89, 100mbit ethernet is the standard. What's a few hundred K when the data is usually the bigger disk hog anyway.
I've just had too many support headaches where we have a machine-specific problem with a legacy mde and nobody knows which is the 'real' source .mdb.
But as I said--it's just my opinion, I could be wrong.
--Jim
RandyMyers
IS-IT--Management
jsteph,
Sorry but I really have to respond here. Most people in this forum would tend to disagree with you on the capabilities of Access. It may be one of the finest application development environments on the market. Unfortunately the opinions you expressed in your post are a down side to Microsoft offering both low end and high end capabilities in one product.
I use Access to develop application front ends connecting to SQL Server databases. Microsoft has stated in several publications that this is their preferred developing environment. They actually referred to it as Visual Basic Access User Interface.
Compiled and creating an mde is a very good way of distributing an application. I would never worry about debugging at the end user’s PC because the end user would never have the DATA at their PC. Even if our company were not the size to use a SQL Server I would separate the data and the front end having only the front end available directly to the user. If for some unusual reason their front end became corrupt it could be simply replaced.
I also live in the real world, and in the real world some incredible applications are created and being used in with Access. And if you use Access Developers Extensions the code can be completely compiled, fully installable applications can be built and distributed with runtimes. The end user would not even know that the application was developed with Access...
Now on the question that was asked in this thread in the first place. No, there is no way of opening an Access 2000 application with Access 97. You must convert the application using 2000, XP (2002) or 2003... If you do not have one of these versions available to you than you must find some one who can convert it for you...
Sorry but I really have to respond here. Most people in this forum would tend to disagree with you on the capabilities of Access. It may be one of the finest application development environments on the market. Unfortunately the opinions you expressed in your post are a down side to Microsoft offering both low end and high end capabilities in one product.
I use Access to develop application front ends connecting to SQL Server databases. Microsoft has stated in several publications that this is their preferred developing environment. They actually referred to it as Visual Basic Access User Interface.
Compiled and creating an mde is a very good way of distributing an application. I would never worry about debugging at the end user’s PC because the end user would never have the DATA at their PC. Even if our company were not the size to use a SQL Server I would separate the data and the front end having only the front end available directly to the user. If for some unusual reason their front end became corrupt it could be simply replaced.
I also live in the real world, and in the real world some incredible applications are created and being used in with Access. And if you use Access Developers Extensions the code can be completely compiled, fully installable applications can be built and distributed with runtimes. The end user would not even know that the application was developed with Access...
Now on the question that was asked in this thread in the first place. No, there is no way of opening an Access 2000 application with Access 97. You must convert the application using 2000, XP (2002) or 2003... If you do not have one of these versions available to you than you must find some one who can convert it for you...
RandyMyers
IS-IT--Management
Hmmm... I think you probably could read the data with up to date mdac????? Never tried that
Randy,
First, I'm not bashing Access, just putting it in it's place.
My rant was more about my personal dislike of mde's, much of which may be based on experiences with them built by non-savvy coders, but much based on true shortcomings. I've made a very good living developing applications with Access, as well as other tools. But the Access ones I've done were inter-company ones--not commercial, 'shrink-wrap' or enterprise apps.
Also, there are certain calls that aren't available in an mde, like dynamically creating/alterin reports, any code which operates on objects in design view, which is a huge timesaver for me, and eases object congestion when I can have a single report that I group differently, or use different controls, etc, instead of having 12 reports that do the same thing but have different controls. An example is a calendar report I use, where not only each month of each year has it's controls in different places, but as the persons schedule changes I span a control across the days as required. It's exceedingly difficult, if not impossible, to do this without the CreateReportControl method. This can't be done in an mde. I suppose I could list some other things that couldn't be done either, and I suppose there's always 'workarounds' or more than one way to skin a cat, but you get the picture.
Yes--for a very simple app that you want to throw together quick & dirty with data that isn't super confidential, then sure--an mde can save you some time. But if I find myself doing all sorts of little 'Island' apps on this persons desktop and that person's desktop, then I think there's a management issue where we need to consolidate requests and think about an larger solution.
Here's an example.
The crew prior to my arrival as a consultant here, would get a request from, say Joe and Bob in accounting. They needed this or that report. So they'd build an mde with an odbc link to enterprise data and a report just for them. Ok, now Tammy and Sue in accounting need a similar report, but they can't see certain fields or need it arranged differently. So this crew builds another mde, on the same data. And on. And on. And on. Many of these people had 5 or 6 of these mde's, each for a different set of reports. And identically named mde's on different desktops connected to different data and had different report layouts. I came here after this had gone on for 3 years and there were--no exaggeration--hundreds of these f'n mde's. There names weren't even the same as what should've been the 'source' mdb's, some had no source mde that myself or the previous crew--which was cooperative, could find. How can you support and debug something when you can't get at the source code? It was a monstrous mess. Some of the stuff had to be reverse-engineered, some trashed and built from scratch. At least with VB there are plenty of source/version control solutions out there.
So anyway I spent a year and now have one app--yes Access, an mdb--that connects to the same data and this same app is has just a few reports, since most reports were on the same data, the grouping or controls might have been different or whatever, and dynamic report design is a huge help. Each user can only view objects I assign him with table-based security. I can change permissions without replacing the mdb, and none of this could be done efficiently with an mde. It's more secure, savvy users can no longer hit f11 and start fiddling with the data as they could and did before, any of our coders can go in with a dev password and debug it on the spot, etc etc.
So I've rambled too much, but I hope I've cleared it up a bit.
--Jim
First, I'm not bashing Access, just putting it in it's place.
My rant was more about my personal dislike of mde's, much of which may be based on experiences with them built by non-savvy coders, but much based on true shortcomings. I've made a very good living developing applications with Access, as well as other tools. But the Access ones I've done were inter-company ones--not commercial, 'shrink-wrap' or enterprise apps.
I'm not sure what you mean here. As far as debugging, data onboard has little to do with debugging. There are now, have always been, and always will be machine-specific issues that you need to work out. Why make it a pain to do so?
Also, there are certain calls that aren't available in an mde, like dynamically creating/alterin reports, any code which operates on objects in design view, which is a huge timesaver for me, and eases object congestion when I can have a single report that I group differently, or use different controls, etc, instead of having 12 reports that do the same thing but have different controls. An example is a calendar report I use, where not only each month of each year has it's controls in different places, but as the persons schedule changes I span a control across the days as required. It's exceedingly difficult, if not impossible, to do this without the CreateReportControl method. This can't be done in an mde. I suppose I could list some other things that couldn't be done either, and I suppose there's always 'workarounds' or more than one way to skin a cat, but you get the picture.
Yes--for a very simple app that you want to throw together quick & dirty with data that isn't super confidential, then sure--an mde can save you some time. But if I find myself doing all sorts of little 'Island' apps on this persons desktop and that person's desktop, then I think there's a management issue where we need to consolidate requests and think about an larger solution.
Here's an example.
The crew prior to my arrival as a consultant here, would get a request from, say Joe and Bob in accounting. They needed this or that report. So they'd build an mde with an odbc link to enterprise data and a report just for them. Ok, now Tammy and Sue in accounting need a similar report, but they can't see certain fields or need it arranged differently. So this crew builds another mde, on the same data. And on. And on. And on. Many of these people had 5 or 6 of these mde's, each for a different set of reports. And identically named mde's on different desktops connected to different data and had different report layouts. I came here after this had gone on for 3 years and there were--no exaggeration--hundreds of these f'n mde's. There names weren't even the same as what should've been the 'source' mdb's, some had no source mde that myself or the previous crew--which was cooperative, could find. How can you support and debug something when you can't get at the source code? It was a monstrous mess. Some of the stuff had to be reverse-engineered, some trashed and built from scratch. At least with VB there are plenty of source/version control solutions out there.
So anyway I spent a year and now have one app--yes Access, an mdb--that connects to the same data and this same app is has just a few reports, since most reports were on the same data, the grouping or controls might have been different or whatever, and dynamic report design is a huge help. Each user can only view objects I assign him with table-based security. I can change permissions without replacing the mdb, and none of this could be done efficiently with an mde. It's more secure, savvy users can no longer hit f11 and start fiddling with the data as they could and did before, any of our coders can go in with a dev password and debug it on the spot, etc etc.
So I've rambled too much, but I hope I've cleared it up a bit.
--Jim
earthandfire
Programmer
jsteph.
With regard to my usage of .mde files, my requirements are obvioulsy very different form yours. From my point of view I use the most suitable database type for the type of application and circumstances.
My usage of .mdes is almost exclusively reserved for applications running on our Citrix server. I keep protected copies of the .mdbs. If a user has a problem, I shadow their session, observe the problem and if a change to the database is genuinely required, the requirement will be for all users. I adjust the .mdb, recreate the .mde, advise all users to log out of and then log back into the database. Testing has confirmed that under this environment .mdes work at a far more acceptable speed than the equivalent .mdbs. Whether this is because of size or pre-compilation or both - or for some other reason, I don't know. To be honest I don't really care why. My requirements on these databases don't require dynamic form/report creation; security and access is set up via Citrix permissions, which is far easier and more effective, at least for our requirements than fiddling around with database permissions. Additional security is provided in the .mde. By setting (disabling) various Access properties, users cannot bypass the interface I provide. The backends in any case are .mdbs.
Whilst I do not disagree with what you are saying, I think you are dismissing .mdes because of the poor way in which you predecessors have used them.
As an aside, when I have to provide a very quick solution to a problem, I tend to use .mdbs not .mdes. Depending on the longer term requirements, I will then remove them when they are no longer needed or incorporate them into the relevant .mde or .mdb or professionalise them as appropriate.
With regard to my usage of .mde files, my requirements are obvioulsy very different form yours. From my point of view I use the most suitable database type for the type of application and circumstances.
My usage of .mdes is almost exclusively reserved for applications running on our Citrix server. I keep protected copies of the .mdbs. If a user has a problem, I shadow their session, observe the problem and if a change to the database is genuinely required, the requirement will be for all users. I adjust the .mdb, recreate the .mde, advise all users to log out of and then log back into the database. Testing has confirmed that under this environment .mdes work at a far more acceptable speed than the equivalent .mdbs. Whether this is because of size or pre-compilation or both - or for some other reason, I don't know. To be honest I don't really care why. My requirements on these databases don't require dynamic form/report creation; security and access is set up via Citrix permissions, which is far easier and more effective, at least for our requirements than fiddling around with database permissions. Additional security is provided in the .mde. By setting (disabling) various Access properties, users cannot bypass the interface I provide. The backends in any case are .mdbs.
Whilst I do not disagree with what you are saying, I think you are dismissing .mdes because of the poor way in which you predecessors have used them.
As an aside, when I have to provide a very quick solution to a problem, I tend to use .mdbs not .mdes. Depending on the longer term requirements, I will then remove them when they are no longer needed or incorporate them into the relevant .mde or .mdb or professionalise them as appropriate.
And I think that's the key. As with any tool, if you do it correctly and methodically it can work for you. Yes, my opinions on mde's were tinged by the experiences I had due to non-savvy coders.
As I said, it's a personal opinion, and what works out for one may not for another.
And I hope it's understood that I do not wish to bash Access, it's been a very good tool for me career-wise, and it's a lot of fun to work with--but it does have it's place. I made the analogy years ago when I was doing a DB2 project on an AS/400, and was asked about the differences in working with Access and the AS/400.
I said that the Access is like a Corvette--a lot of fun to drive, flexible, handles well, looks great. The AS/400 is like an ugly smoke-belching semi truck. But if I've got 200 TV sets to move from here to LA this week--the 'Vette just has no business attempting that.
--Jim
RandyMyers
IS-IT--Management
jsteph,
I appreciate your clearing up your statements and I agree your situation would cause me to dislike mde's also. Unfortunately the issues you described were pure and simple poor work and organizational skills by your predecessor.
I believe an mde is the best way to distribute a fully developed application. Like others have stated I keep a secure mdb as the development module and then use Access Developers Extensions to create the mde for distribution.
I use SQL user groups for security which seems to work best for me since these can integrate in with our Active Directory and the end user's login determines what data they can see or modify.
I also love the installation packages that the Developers Extensions can create. I set the applications up to open in run time mode. Therefore Access does not even launch and for that matter is not required on the PC running the application. The end user just runs the application and has no knowledge that this application was originally developed in Access. Since the final distribution module is fully converted to VB it is fully compiled and extremely fast.
I appreciate your clearing up your statements and I agree your situation would cause me to dislike mde's also. Unfortunately the issues you described were pure and simple poor work and organizational skills by your predecessor.
I believe an mde is the best way to distribute a fully developed application. Like others have stated I keep a secure mdb as the development module and then use Access Developers Extensions to create the mde for distribution.
I use SQL user groups for security which seems to work best for me since these can integrate in with our Active Directory and the end user's login determines what data they can see or modify.
I also love the installation packages that the Developers Extensions can create. I set the applications up to open in run time mode. Therefore Access does not even launch and for that matter is not required on the PC running the application. The end user just runs the application and has no knowledge that this application was originally developed in Access. Since the final distribution module is fully converted to VB it is fully compiled and extremely fast.
Hi,
Its a bit gray area between choosing mde or mdb as deployment choice. I guess many of us work in maintaining/developing in-house databases where we don't care about source code being readable and sometimes we do need to fix a tiny bug at users machine while user is bit impatient and then go back and fix the bug at the original version and release update.
But I will certainly agree that rectifying errors at users desk is not the preferred way. They should always have mde specially when database has become quite stable after few months of continous bug fixing.
As far the tiny difference in performance is concerned, users do notice a difference in speed specially when it comes to running database over networks. If the difference is in nano seconds while its running on your local drive, it actually translates in to 1-2 seconds when it runs on network. So I will opt for anything which brings better performace in terms of speed and mde does makes a difference.
I will agree with jsteph on disk size issue as its no longer a big concern as most of the medium sized access databases tend to be between 50-300MB in anyway.
I strongly believe that Access is the most user friednly and quick database development tool. It not only gives a lot of built-in features but it also gives you huge power in flexability with VBA. Its sometimes the most critised and most under rated tool around. It does perfect job for handling most of our needs and at a very cheap rate both in terms of cost and time.
Cheers!
ÙÇãá
It's important to learn the rules so that you know how to break them.
Its a bit gray area between choosing mde or mdb as deployment choice. I guess many of us work in maintaining/developing in-house databases where we don't care about source code being readable and sometimes we do need to fix a tiny bug at users machine while user is bit impatient
and then go back and fix the bug at the original version and release update.But I will certainly agree that rectifying errors at users desk is not the preferred way. They should always have mde specially when database has become quite stable after few months of continous bug fixing.
As far the tiny difference in performance is concerned, users do notice a difference in speed specially when it comes to running database over networks. If the difference is in nano seconds while its running on your local drive, it actually translates in to 1-2 seconds when it runs on network. So I will opt for anything which brings better performace in terms of speed and mde does makes a difference.
I will agree with jsteph on disk size issue as its no longer a big concern as most of the medium sized access databases tend to be between 50-300MB in anyway.
I strongly believe that Access is the most user friednly and quick database development tool. It not only gives a lot of built-in features but it also gives you huge power in flexability with VBA. Its sometimes the most critised and most under rated tool around. It does perfect job for handling most of our needs and at a very cheap rate both in terms of cost and time.
Cheers!
ÙÇãá
It's important to learn the rules so that you know how to break them.
I'm all for user's seeing tangible performance benefits, but I'm not sure an mde does anything to increase network performance or file-access performance compared to an mdb.
Yes, pre-compiled code can increase code execution speed and a smallar disk footprint *may* reduce the initial opening time of the app, but again--with the data separate we're usually only talking a few hundred K of human-readable code and comments that's removed from the final version.
I agree that Access is the most friendly and quick development tool, but again--for it's intended scope. I wish there were an 'Access-like' tool for Oracle or SQL-Server, one that combined everything into one package. For now, I can use Ora-or-SQL backends with an access front end for the smaller stuff--and for prototyping and metadata larger stuff.
I have used Access *in some way* in probably 95% of my projects--but maybe only 60% as the main app. In one memorable project I used it to manage metadata--tablenames,fieldnames, objectnames, etc--with 700+ tables and roughly 7000 fields, Access fit nicely as a way to manage the metadata. It also was a massive timesaver as I used it to generate blocks of code for the VB front-end--each form had a relatively set pattern as far as using sql to load the textboxes, update the record, etc, so writing vba code in access against the tables that held table, field, and formnames was an incredible expedient--as well as a way to standardize code. There's no other tool that could have done that so well.
Again...I wasn't underrating Access, just the .mde.
--Jim
- Status
Similar threads
- Locked
- Question
- Locked
- Question
- Locked
- Question