Future of Access

  • Thread starter Thread starter Louverril
  • Start date Start date
L

Louverril

I would like to use accesss to create a software package to sell.

However I hear that VBA will no longer be supported from teh next version of
Office.

I also here that .net is a nightmare to learn.


What shoudl i write the package in. around 10 tables estimated 17 forms (inc
subforms).

Thanks Lou
 
Louverril said:
However I hear that VBA will no longer be supported from teh next version of
Office.

RUBBISH!!!! The next version of Office will have VBA in it.
Furthermore there are lots of developers, testers and PMs and
Microsoft working on Access. It is not dead.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
 
RUBBISH!!!! The next version of Office will have VBA in it.
Furthermore there are lots of developers, testers and PMs and
Microsoft working on Access. It is not dead.

Indeed, VBA is even being put back in the next version of MacOffice,
after being left out of MacOffice 2008.
 
Tony Toews said:
RUBBISH!!!! The next version of Office will have VBA in it.
Furthermore there are lots of developers, testers and PMs and
Microsoft working on Access. It is not dead.

Just to add to what Tony had to say:

From Version 1.1 on, there has always been _someone_ whispering rumors about
the impending demise of Access itself, or of some important
feature/function. It has almost been as if there were an active
"anti-Access underground", but I suspect it has actually just been users of
other DB software who (quite rightly) felt threatened that Access was
outdoing their software and were "just hoping" that some rumor would "stick"
and drive away Access customers.

As to VBA... VBA was dropped from the Apple Macintosh version of Microsoft
Office 2008, but the howl of anguish from Mac users of Office was so great
that it has been announced that the next version of Mac Office will again
have VBA (note that Mac Office does not include a Mac version of Access, in
any case). As rumors strengthened, about that time, that VBA would
disappear from Windows Office, I believe the howls of anguish that it might
not be in future versions of Access were loud enough to change the mind of
anyone in Redmond who might have had such an idea.

Certain features of Access have been dropped or de-emphaisized, from time to
time -- some examples are Data Access Pages (DAP), Access Projects (ADP),
and Access' Workgroup Security. In the case of the first two, it appears
that Microsoft overestimated user demand for what they introduced and users
were not so eager that they would live through the limitations of the
earlier releases in hope that things would get better. In the case of the
last, that was useful sometimes in keeping users of developed databases from
stumbling over their own fingertips and getting in trouble, but the security
has been easily crackable for a long time. It finally got SO crackable that
you can, for free, find a downloadable package that will break security on a
well-secured database even if you do not have the Workgroup file to go along
with the database you are trying to break into.

But, neither DAP nor ADP were "widely used" and existing databases in both
will still run, and in fact, though new features were not included in ADP,
it was updated and you can still develop and maintain ADPs in Access 2007.
Data can be secured by using a server databases' security if you are using a
server DB (e.g., Microsoft SQL Server, or one of the Sybase products, or
Oracle, or IBM DB2 or Informix, or other ODBC-compliant database) as your
datastore, or if you use Microsoft Office Sharepoint for that purpose, as
you now can, it also has its own security.

Like Tony, I am aware that extensive effort still goes into new releases of
Access, and I've seen no indication from any 'Softie that Access itself, or
any substantially-useful feature, might be dropped.

That said, because Access' own security was not strong, and because it has
been dropped from the new ACCDBs of Access 2007, I would think long and
carefully before using it to create a commercial software package. I've
been doing Access development since version 2, but mine has always been
"bespoke systems" for particular users, not for "shrink-wrap" or
"downloadable" commercial or shareware apps.

As I've never looked into creating the kind of application you are
considering, I wouldn't be a good source for discussing alternatives. I am
_not_ a fan of Visual Studio, though, and that's no secret.

Larry Linson
Microsoft Office Access MVP
 
Larry Linson said:
From Version 1.1 on, there has always been _someone_ whispering rumors about
the impending demise of Access itself, or of some important
feature/function.

I was thinking of adding the same comments there.
It has almost been as if there were an active
"anti-Access underground", but I suspect it has actually just been users of
other DB software who (quite rightly) felt threatened that Access was
outdoing their software and were "just hoping" that some rumor would "stick"
and drive away Access customers.

I've always thought it was IT managers and such who had drunk the
latest .Net koolaid and such. Including listening to Microsoft's own
employees who were derisive of Access's capabilities.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
 
Tony Toews said:
I've always thought it was IT managers and such who had drunk the
latest .Net koolaid and such. Including listening to Microsoft's own
employees who were derisive of Access's capabilities.

Pushing .NET is a well-funded campaign.

MS Developer Evangelists don't get many (any?) points for saying nice things
about Access, but they look good if the stats for installed copies of SQL
Server and Visual Studio in their District have risen. If only they
understood how to play the game, they'd be pushing Access as the client for
MS SQL Server and pushing for lots of little starter db apps to be done; or
pushing Access as a client for the customer's non-MS database to 'get a foot
in the door'.

The latter happened at a couple of places where I contracted. No MS SQL
Server installs (and of course no MS SQL Server databases) when we came on
to front-end Sybase in one situation and Informix in another. But there was
an MS SQL Server installation and at least a couple of databases with Access
clients, just due to "looking over our shoulder". And, hey, we weren't
'Softies and weren't there to sell new software -- it just sorta sold
itself.

Larry
 
Larry thanks very much for the extensive reply.

Picking up on what you ay about security. Which aspect of security do you
mean? The database will be single user (no user id) - I'll probably add a
password - I'll make this clear even if they want to install multiple front
ends and have the data part on the network (where they can set thier own file
permissions anyway). Most of the smaller packages I see sold have fairly
basic user control anyway?

Or do you mean the issue of reinstalling "pirate" versions? I think I've got
this covered.

Let me know if I'm missing something.

Thanks
Lou
 
The overall database password security has been so easily "crackable" that
it has never been more than a sometimes-pain to legitimate users. Workgroup
Security is also crackable... with a very little searching, you can find a
freely-downloadable application that will break security on even a
properly-secured Access 2000, 2002, or 2003 database, (and, separately, on
some earlier versions) even if the MDW file is not available (which used to
be a stumbling-block for a lot of tries at cracking). Now, the approach is
to simply determine the owner and the associated keyword so you can build
your own, new MDW, or copy the objects to an unsecured DB.

I don't know how you plan to cover "reinstalling pirate versions" -- there
are some very clever "crackers" out there, and they seem to be able to
"crack" security on just about every commercial or shareware software
package in short order. Any Access package would, of course, be "less
interesting" to them because it would, almost certainly, be a "niche" market
application, with far fewer potential users than a new spreadsheet or game
or ???

If you intend to implement your own password scheme, I'd just shrug and say
that will be even less effective than Access' own security. If you use
Access' own Jet or ACCDB database engine, then every user will have to have
full permissions (create, destroy, read, write, update, delete...) on the
shared folder where the tables (aka Back End) DB is stored.

The vast majority of Access database applications that I have done for
clients, where data security was an issue, were Access clients to a sever
database (e.g., Microsoft SQL Server, Informix, or Sybase products) and
relied on the server DB's security to secure the data.

Larry Linson
Microsoft Office Access MVP
 
Thanks Chris,

I watched this presentation from tech ed on the Access Team blog 19th June
08 : http://blogs.msdn.com/access/rss.xml and although it's title is about
migrating to SQL Server it really helps to explain where Access fits in and
how "over the top" creating a back end SQL Server can be for situations where
there are only a relatively small number of users.

It convinced me that Microsoft would be "mad" not to push Access. Probably
the main point being that it's so cheap to develop in Access and why spend
all the cash on SQL Server development (or even more cash on adding .net)
for a relatively small system. Ok so if it needs upgrading in a few years
fine you haven't lost anything. Many other good points were also raised.

Dissapointing there was hardly anyone in the audience though - is that
normal at Tech Ed in the US?

Cheers,
Lou.
 
Thanks Larry,

Ref. pirate vesions. I suppose everything is "crackable" it's just about
making it as difficult as possible. There are intnernet based license
checkers that you can use. Plus you are right it'll be fairly niche.

See your point about server permissions on the back end accdb but they can
be limited slightly and still use the database (only need read and update?)
and these can be limited to the group of people allowed to udpate the
package. You can also have a read only version available if time isn't
crucial - we used to use this very sucessfully at a company I worked for once.

Cheers Lou
 
If you use
Access' own Jet or ACCDB database engine, then every user will
have to have full permissions (create, destroy, read, write,
update, delete...) on the shared folder where the tables (aka Back
End) DB is stored.

Er, "destroy" permission? Never heard of it.

And they don't need DELETE permission. If you don't give them delete
permission, they can't "accidentally" delete the back end data file.
Also, the LDB file won't be deleted when the last user exits, but
that just means Access will be operating like Access 2 and before,
where the LDB was not deleted on exit. There can be some minor
issues with that, but if preventing the "accidental" delete is an
issue for you, it can be worth the trade-off of having a persistent
LDB file.
 
Do they need "create"?

Thanks Lou

David W. Fenton said:
Er, "destroy" permission? Never heard of it.

And they don't need DELETE permission. If you don't give them delete
permission, they can't "accidentally" delete the back end data file.
Also, the LDB file won't be deleted when the last user exits, but
that just means Access will be operating like Access 2 and before,
where the LDB was not deleted on exit. There can be some minor
issues with that, but if preventing the "accidental" delete is an
issue for you, it can be worth the trade-off of having a persistent
LDB file.
 
Louverril said:
Do they need "create"?

I suppose if you don't allow delete and can therefore assume that the LDB
file will never be deleted, then perhaps you can also forego create
permissions. You would need one person with create permissions to create
the LDB initially though. In addition, the LDB will need to be manually
deleted to perform the occassional compact on the file. Then an initial
create would have to be performed again.

Given the potential complications I see little reason to remove create
permissions.
 
Rick Brandt said:
I suppose if you don't allow delete and can therefore assume that the LDB
file will never be deleted, then perhaps you can also forego create
permissions. You would need one person with create permissions to create
the LDB initially though. In addition, the LDB will need to be manually
deleted to perform the occassional compact on the file. Then an initial
create would have to be performed again.

I've heard of cases where the permissions were set such that users could not
update files they didn't own, meaning that they were unable to work with an
LDB file created by someone else. Of course, that'll be a problem whether
they have create permission or not.
 
Thanks Rick - sensible answer!

Rick Brandt said:
I suppose if you don't allow delete and can therefore assume that the LDB
file will never be deleted, then perhaps you can also forego create
permissions. You would need one person with create permissions to create
the LDB initially though. In addition, the LDB will need to be manually
deleted to perform the occassional compact on the file. Then an initial
create would have to be performed again.

Given the potential complications I see little reason to remove create
permissions.
 
not sure I agree.

ADP are _VERY_ popular.

I can name more ADP users in Seattle than MDB right now.

-Aaron
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Back
Top