469,323 Members | 1,639 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,323 developers. It's quick & easy.

Future of access?

Hi

What future does access have after the release of vs 2005/sql 2005? MS
doesn't seem to have done anything major with access lately and presumably
hoping that everyone migrates to vs/sql.

Any comments?

Thanks

Regards

Nov 13 '05
64 4553
On Sun, 12 Jun 2005 20:54:06 -0700, "(PeteCresswell)" <x@y.z.invalid>
wrote:
Per Lauren Wilson:
WHY
would anyone WANT to convert an existing, widely deployed Access
application into VB.NET? IOW -- is there any value in doing so?
A few that came to my mind:
-------------------------------------------------------------------
1) Somebody needs to bill about a bizillion more hours to that client.


Is this a legitimate concern when comparing the two technologies
(VB.NET versus Access for FE dev)? If so, why?
2) The client does not want to live with the MS Access version thing hanging
over their head. i.e. Maybe the app is so widely deployed in so many divisions
that when a new version of MS Office and the attendant new version of Access
comes out that just a bunch of blind installs will render the app un-runnable by
most users.
Hmmm. Have rarely encountered this problem with our 5 year old app.
3) The client wants to deploy the app over the web.
Already doing this. What's the problem?
4) The client wants to run the app over the web.
Oh God no! Never! The web is great for consumption and output
distribution but NOT for serious, high volume read/write transactions
-- at least not yet!
5) The client's IT people are starting to jump ship because they want jobs that
will expose them to more cutting-edge development environments.


This assumes an issue not elaborated here. "Cutting edge" does not
necessarily mean long life cycle. "Cutting edge" often means little
more than the latest pop-fad, glommed onto by newly graduated IT kids
with little real world business experience. Remember Paradox for
Windows? Brilliant, well executed development system. It lasted
about two years before a death spiral to oblivion. Go figure.

Nov 13 '05 #51
On Mon, 13 Jun 2005 01:06:46 GMT, "David W. Fenton"
<dX********@bway.net.invalid> wrote:
"(PeteCresswell)" <x@y.z.invalid> wrote in
news:ii********************************@4ax.com :
Per Lauren Wilson:
WHY
would anyone WANT to convert an existing, widely deployed Access
application into VB.NET? IOW -- is there any value in doing so?


A few that came to my mind:
-------------------------------------------------------------------
1) Somebody needs to bill about a bizillion more hours to that
client.

2) The client does not want to live with the MS Access version
thing hanging over their head. i.e. Maybe the app is so widely
deployed in so many divisions that when a new version of MS Office
and the attendant new version of Access comes out that just a
bunch of blind installs will render the app un-runnable by most
users.

3) The client wants to deploy the app over the web.

4) The client wants to run the app over the web.

5) The client's IT people are starting to jump ship because they
want jobs that will expose them to more cutting-edge development
environments.


Don't you agree that most of these are not particularly *good*
reasons to avoid Access?


Yes -- with the possible exception of the IMPLICATION of #5: Is Access
considered "cutting edge" or not -- by anyone that matters? Indeed,
is there even an objective means of identifying a "cutting edge"
development technology that is LIKELY to have a long life cycle?
Nov 13 '05 #52
Per David W. Fenton:
Don't you agree that most of these are not particularly *good*
reasons to avoid Access?


I don't cite them as good reasons - just reasons that a client might have.

The deployment thing is something that I always raise on prospective new
projects, as is the over-the-web issue - although I always qualify that with an
explaination of products like PC Anywhere and Citrix.
--
PeteCresswell
Nov 13 '05 #53
"(PeteCresswell)" <x@y.z.invalid> wrote in
news:4r********************************@4ax.com:
Per David W. Fenton:
Don't you agree that most of these are not particularly *good*
reasons to avoid Access?
I don't cite them as good reasons - just reasons that a client
might have.


Well, I don't think you, as a pro in the field, should be neutral on
those reasons, and that's why I responded casting doubt on their
validity. I think that's *your* responsibility, too.
The deployment thing is something that I always raise on
prospective new projects, as is the over-the-web issue - although
I always qualify that with an explaination of products like PC
Anywhere and Citrix.


Yes, I, too, always discuss the issue of remote usage (rather than
"over-the-web", which is already an answer limited to one solution),
and where the infrastructure supports it, push Windows Terminal
Server (I don't see that Citrix is required much any longer).

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
Nov 13 '05 #54
Per David W. Fenton:
push Windows Terminal
Server (I don't see that Citrix is required much any longer).


I just installed the client on my home PC and the HelpDesk at a site where I'm
working enabled it for my PC at their site.

Geeze!!!! Must've taken a grand total of fifteen minutes to get it running and
response time using Covad DSL is not all that bad.

For situations where each user has their own PC at work and they're concerned
about being use the app from home and have broadband, this seems to resolve many
"Web" issues (the term "Web" being used from the user's perspective as "Can I
use it from home?")
--
PeteCresswell
Nov 13 '05 #55
"(PeteCresswell)" <x@y.z.invalid> wrote in
news:9v********************************@4ax.com:
Per David W. Fenton:
push Windows Terminal
Server (I don't see that Citrix is required much any longer).
I just installed the client on my home PC and the HelpDesk at a
site where I'm working enabled it for my PC at their site.

Geeze!!!! Must've taken a grand total of fifteen minutes to get
it running and response time using Covad DSL is not all that bad.


The performance for me is good enough that for one of my clients I
do all my development work for them on WTS.
For situations where each user has their own PC at work and
they're concerned about being use the app from home and have
broadband, this seems to resolve many "Web" issues (the term
"Web" being used from the user's perspective as "Can I use it from
home?")


That was precisely my point.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
Nov 13 '05 #56
"(PeteCresswell)" <x@y.z.invalid> wrote in
news:9v********************************@4ax.com:
Per David W. Fenton:
push Windows Terminal
Server (I don't see that Citrix is required much any longer).


I just installed the client on my home PC and the HelpDesk at a
site where I'm working enabled it for my PC at their site.

Geeze!!!! Must've taken a grand total of fifteen minutes to get
it running and response time using Covad DSL is not all that bad.

For situations where each user has their own PC at work and
they're concerned about being use the app from home and have
broadband, this seems to resolve many "Web" issues (the term
"Web" being used from the user's perspective as "Can I use it from
home?")


Also, keep in mind that you get the advantage of centralized
administration.

It's not zero client installation as with a browser-based
application, but it's very close to it. And you get the advantage of
being able to use your Access application anywhere, without needing
to replace it or re-engineer it (with the inevitable loss of
features).

If Windows 2000 had been released one year earlier, one of my
clients could have saved the $200K they spent replacing my $35K app.

Of course, that never would have happened, since the only real
reason they replaced it was that the new management didn't like my
app (or me, for that matter). The developers who replaced me
admitted during conversations I had with them helping import the
data that their app was not nearly as full-featured as mine -- they
admitted to be in awe of what I'd accomplished with Access, because
they'd had no idea what was possible.

The client was also trying to get multi-site support (we'd been
using replication), but it turned out that they didn't really get
that in the form they thought they were. Their administrative costs
went up, instead of down.

If they'd waited one year, they could have kept the old app and
their existing replication-related admin costs could have dropped to
ZERO.

And, by the way, they went out of business about 2 years after
abandoning my app.

I fully recognize that correlation does not prove causation.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
Nov 13 '05 #57
"(PeteCresswell)" <x@y.z.invalid> wrote:
I don't know why you'd want to use unbound forms except in some
special circumstances.
My theory is that unbound forms help to make the app more bulletproof.

Instead of somebody sitting on a record - and maybe turning off their PC or
something, the app just hits the DB for a fraction of a second to populate the
form and then it's out of the back end.


Whereas I've been on site at one client for at least three or four
power failures and they've never had a corruption. I'm sure at least
four or six users were in adding or editing a record each time the
power went out.

Note that the switches and servers were on UPS..

I'm much more concerned with that millisecond of time when they do the
update. And there's no real difference between bound and unbound
forms for that time duration.
For me they also facilitate "Browse" and "Edit" modes with "Save" and "Cancel"
by enabling the programmer to do quite a bit more cross-checking/validating
before anything goes out to the back end.
Yeah but that's not a bid deal to me.
Maybe this is all BS - but I've been doing unbound forms for so long that
they're second nature (i.e. quick and easy to clone...) whereas every time I've
tried reverting to bound forms the users have come up with a requirement that
broke my little scheme. OTOH, maybe I just haven't developed the skill set
needed to deal with some of those situations in bound forms...


<smile> Or maybe you just think sideways too much.

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
Nov 13 '05 #58
Per David W. Fenton:
Also, keep in mind that you get the advantage of centralized
administration.


I'm guessing that the same technology allows somebody to set up a sort of
'server' that many people can hook into - each running their own vitrual PC.

Have I got it right? Or do the clients need a separate onsite PC for each
person connecting?
--
PeteCresswell
Nov 13 '05 #59
"(PeteCresswell)" <x@y.z.invalid> wrote in message
news:jt********************************@4ax.com...
Per David W. Fenton:
Also, keep in mind that you get the advantage of centralized
administration.


I'm guessing that the same technology allows somebody to set up a sort of
'server' that many people can hook into - each running their own vitrual PC.

Have I got it right? Or do the clients need a separate onsite PC for each
person connecting?


With Windows Server you can have as many remote users as your resources will
support. With normal WinXP you can have only two connections and they have to
have admin authorities. Technically the "remote desktop" feature is intended
for doing administration on the box from another location and while it is in use
the PC cannot be used locally.

It should be pointed out to that the remote users still have to have licenses
for all the software on the server that they use in addition to a CAL license to
use the server at all. It solves some remote performance problems, but it is
not necessarily inexpensive and while it solves some administration issues it
introduces a few of its own (Email and printing being two notable ones).
--
I don't check the Email account attached
to this message. Send instead to...
RBrandt at Hunter dot com
Nov 13 '05 #60
"Rick Brandt" <ri*********@hotmail.com> wrote in
news:r7*****************@newssvr12.news.prodigy.co m:
"(PeteCresswell)" <x@y.z.invalid> wrote in message
news:jt********************************@4ax.com...
Per David W. Fenton:
Also, keep in mind that you get the advantage of centralized
administration.
I'm guessing that the same technology allows somebody to set up a
sort of 'server' that many people can hook into - each running
their own vitrual PC.

Have I got it right? Or do the clients need a separate onsite PC
for each person connecting?


With Windows Server you can have as many remote users as your
resources will support. With normal WinXP you can have only two
connections and they have to have admin authorities. Technically
the "remote desktop" feature is intended for doing administration
on the box from another location and while it is in use the PC
cannot be used locally.


I was not talking at all about workstation-to-workstation Remote
Desktop -- I think that's a valid configuration for deploying an
Access app only in the must rare of circumstances, e.g., like what
we recently discussed here in the newsgroup where someone had two
offices and was carrying data back and forth, but was only ever in
one office at a time (with no other people using the PCs, either).
For him, workstation-to-workstation remote desktop was perfect,
since it was two PCs used by one person.

I was suggesting Windows Terminal Server, which comes as a part of
Windows Server starting with Windows 2000 Server. By default, it,
too, supports the two administrative users, but in multi-user mode.
That is, somebody can be at the server console while someone is also
running a remote session (I'm not sure if that extends to one at the
console with two remote sessions, though).

To have non-administrative users run an app on WTS, you need to buy
the CALs to enable additional logons. They run $30-40 each (no
volume discounts), depending on academic discounts and so forth.
It should be pointed out to that the remote users still have to
have licenses for all the software on the server that they use in
addition to a CAL license to use the server at all. It solves
some remote performance problems, but it is not necessarily
inexpensive and while it solves some administration issues it
introduces a few of its own (Email and printing being two notable
ones).


But the licensing is fairly loose -- old versions of MS Office apps
get you permission to use later versions (I don't have Office 2K3,
but I can run Access 2K3 on one of my client's WTS installation).

Of course, you *do* have to have *some* version of Access, or, at
least, of Office (not sure whether Office apps bring cross-licensing
for using different apps you don't have installed). In all the
circumstances where I've implemented it, we were replacing
locally-run apps, so everybody had Access locally installed.

Also, Win2K3 Server comes with pretty good printer redirection
(i.e., when you're logged on to the WTS, your local printer gets
detected and you have the ability to print from the remoted WTS
session and have it print on your local printer), while if I'm not
mistaken, Win2K Server had none unless you bought the Citrix
extensions. However, it's no panacea -- the WTS server's Windows
installation can only detect printers for which it has the drivers
already installed. That means that if the remote users have printers
that predate the release of Win2K3 Server, they'll be golden, but if
they have newer printers, it won't. Installation of the newer
printer drivers on the server takes care of it, which is fine if
you've got a bunch of remote users with the same brand of printer
(since most printer installers install classes of drivers, not just
for an individual printer), but if you've got a mix of printers,
it's more of a problem. I've only had the former experience, since
everyone connecting was under the same purchasing authority and had
compatible printers (i.e., only a couple of printers had to be
installed on the server).

The other gotcha is the weird licensing server software. You have a
choice between device licenses and user licenses (not both), which
means that licenses are allocated either to the connecting PC or
tied to the user logon. The system was designed on the assumption
that everyone would choose the former, so that when you use the
latter (which makes more sense to *me*), there are weird
inconsistencies (such as lack of reporting of license use and
availability in the licensing manager -- minor detail -- *NOT*!).
But once it's up and running, it's great.

I do replication now only with laptop users and the occasional
two-PC operation where they want to share data between a couple of
locations. I'm partnering in a project with one of my clients who
already had a replicated back end, and I'm now doing indirect
replication via Replication Manager between their main PC and mine
across a Win2K-to-Win2K VPN (using the default Windows VPN client).
It's a breeze, and works very well (with broadband cable on both
ends). The only hitches have been figuring out exactly which ports I
need to authorize the client's PC through my software firewall (that
wouldn't be an issue with a hardware firewall, because everything
would be going through the VPN's port(s)).

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
Nov 13 '05 #61
Microsoft is on CRACK.

Access rocks.

They sit around and try to sell us all on a language that is TWICE as
hard to develop in-- but it gives us 5% better performance.

I mean-- I DONT NEED BETTER PERFORMANCE MICROSOFT I NEED YOU TO FUCKING
FIX BUGS IN YOUR CURRENT PRODUCTS

pos company

Nov 13 '05 #62
you're crazy .NET is TEN TIMES MORE DIFFICULT AND SLOWER TO DEVELOP
WITH

take your MVP and shove it babe

you work for the devil? sure sounds like you do

Nov 13 '05 #63
Access is the best reporting platform in the world and Microsoft isn't
taking it seriously.

I call for the resignation of every Microsoft executive in charge of
Access
you have been smoking crack and selling 'smoke and mirrors' instead of
doing your job

fix your bugs microsoft

Nov 13 '05 #64
..net does have a place.

..net is best written using MACROMEDIA DREAMWEAVER.

Microsoft can't write a decent IDE anymore.. they're on crack

Nov 13 '05 #65

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

47 posts views Thread by David Eng | last post: by
18 posts views Thread by Ghost Dog | last post: by
5 posts views Thread by PetitTrot | last post: by
2 posts views Thread by FilterXG | last post: by
33 posts views Thread by Uwe Range | last post: by
2 posts views Thread by =?Utf-8?B?Sm9ubnk=?= | last post: by
reply views Thread by zhoujie | last post: by
reply views Thread by suresh191 | last post: by
reply views Thread by Gurmeet2796 | last post: by
reply views Thread by harlem98 | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.