MDB or ADP
-
Hi,
I'm new to SQL server, but creating basic application for the past 8 months now with SQL server backend and access 2000 client(.adp) frontend.
Previously, I have used access(.mdb) - no sql connection only to another mdb file, and was able to secure it to stop clients messing around. With the recent transition to .adp I find that I can lock the modules with a password and nothing else. Client can still see and view everyting else.
To all you SQL gurus out there, what is your choice as a client frontend, bearing in mind I have not moved to vb or vb.net yet.
Thanks in advance.
-
You can acutally send an ADE (compile module). where the user will only access what you want them to (with menus/forms). They won't be able to access anything else.
-
Remi is correct. Furthermore, you should never distribute an ADP. In short:
ADP = Source Code
ADE = compiled version for distibution
Forget about the VBA password. It's a joke that takes 5 seconds to crack.
-
Hi all,
I really like working with ADP. However, the existence of this platform is really suspect in later versions of MS access. ADP is cleaner and closer to true visual basic .net code. It is also not subject to as much bloating becuase it is a better front end to sql server. However, I have moved all my adp applications to vb.net, I would recommend you do the same. It's easier than you may think. Good luck
-
"the existence of this platform is really suspect in later versions of MS access."
Karim, this is a baseless rumor started by one particular well-known newsgroup poster. I have not heard or read anything from MS that would indicate ADPs will be phased out. In fact, in one interview I read about the next version, there was a brief cryptic discussion of ADP use in the next version. It's clear that ~95% of Access users use MDBs, because 95% of database projects are quite small, and require minimal security. That's why MS talks primarily about MDBs.
Sure, .NET is a truly fantastic platform ...... but not for databases, at least not yet. You will quadruple (at least) your development costs by going to .NET. A single-developer database will become a team effort. Creating a "nice" form takes 8 days instead of 8 hours. .NET is NOT a RAD database develoment tool. It is a full featured language platform, that happens to support databases somewhat. Every time a new version comes out, they change the basic ADO.NET object and overhaul the database development model. Still no server-side cursors. No managed Pivot tables or charts. No switching between datasheets and forms and Pivot views. No automatic server or client filtering. No query by form. The list goes on and on. I would bet the the database development failure rate (failed project rate) on .NET is 10 times the rate for Access.
It's really a pity, because MS could easily implement a complete Access-like form class supporting all the familiar Access RAD features in the new Visual Studio. But apparently, they don't want it to compete with Access????
Sure, if you have a really simple app, or a large dev team, go for it, just for fun. But there's no way I'm going to convert an app with hundreds of forms, hundreds of tables, and 100,000 lines of code to .NET, and still stay in business.
On the other hand, I am looking closely at COM Interop for my Access projects in order to implement some more complex "business rules" (I hate that term) in .NET. In other words, things I used to do in VB6 (e.g. some bulk data processing, cryptography, graphics), I am planning to convert to .NET (2005).
Just my $0.02
-
We use ADPs quite a bit for user interfaces. Keep in mind, if you decide to use them, that there are some object model differences between Office versions (particularly Office 2K and 2K3); ADPs coded for Office 2K Access may have some trouble running on Office 2K3 if you use certain functions (email, visibility properties in macros, etc.). I've had to maintain multiple versions of some of our ADPs because one user hitting it with 2K3 will reset the references and then 2K users see it blow up.
-
ive had (what sounds like) a similar problem with references (in my case creating a mdb/mde on my development machine and pushing it out to everyone, and having some machines fail due to references)
I solved it by doing the following
- finish current version
- copy to machine with reference problem
- repoint the couple of bad references to valid equivalent ones (in my case its the office web browser function library reference)
- create .mde on that machine and distribute
bingo - the nice not so up to date machine makes sure i create older references that everything seems to like and it works everywhere
may or may not work in your case
(my dev. machine still likes the old references version too even though it doesnt have them - i guess thats office spotting older references and repointing them at its more up to date versions automagically)martin
Viewing 7 posts - 1 through 6 (of 6 total)
You must be logged in to reply to this topic. Login to reply