Our IT guys are on a vendetta against MS Access (and Lotus Notes but they've
won that fight). What I can't understand is, what's the problem? Why does
IT hate MS Access so much.
I have tried to find out who it is that actually wants to get rid of it, but
I can't find anyone who will admit to trying to get rid of it. Nevertheless,
I'm always hearing about how their "phasing it out" or "getting rid of it".
Because no-one owns up I can't even have an open debate about the pros and
cons of MS Access.
It is certainly amazing what disinformation is out there about what MS-Access
can and can't do. "MS Access clogs up the network". Well yeah... when IT
forces you to install the client of your client server app on the Network
Server it does. How come IT developer's clients can reside on the PC, but a
non-IT developer's client can't? "MS-Access requires you to download a copy
of the data before you can create a management report". Well no, we have a
thing called ODBC. "MS-Access doesn't let you set up views/derived
tables/abstraction layer/ multi-dimensional cubes blah, blah, blah" Well,
actually,... it does! "MS-Access can't publish reports to the web" Wrong!
"You can't upgrade Access 95/97 apps to Access 2000/2003/XP". Bzzzt! Wrong
again!
Meanwhile MS-Access has a number of exceptional strengths (a) an (almost)
comprehensive SDK (b) its cheap (c) lots of people have skills in it (no
$1500/day for an MS Access developer) (d) its well integrated with a
spreadsheet, a wordprocessor and its operating system (e) it's context
sensitive help is nothing short of fabulous (f) it has few limitations with
regard to aggregating aggregates or filtering by aggregates, maintaining
previously calculated data, etc etc. Look I could go on, but I have no
forum to argue my case.
So what is it? Is it the security model of Access? Is it the fear that IT
will be left holding the undocumented spaghetti-coded baby when the non-IT
developer skips town? Is it just that it's Microsoft, and its cool to thumb
your nose at Bill Gates? Or is it that IT doesn't like non-IT people having
access to the VB coding environment which can be used to overcome PC and
possibly Network security? Or is it something else?
I used to be in charge of Oracle DBAs and have been responsible for an
organisation's data management policy. I had nothing against MS Access then.
So what's the deal?
Regards,
Jeff Popova-Clark
Gold Coast Australia
--
Message posted via AccessMonster.com http://www.accessmonster.com/Uwe/For...ccess/200509/1 92  7540 
On Tue, 27 Sep 2005 01:23:19 GMT, "Jeffrey P via AccessMonster.com"
<u12062@uwe> wrote: Our IT guys are on a vendetta against MS Access (and Lotus Notes but they've
won that fight). What I can't understand is, what's the problem? Why does
IT hate MS Access so much.
MS Access gives non-programmers the ability to create applications that become
indispensible to an organization and then must be maintained by IT. The
trouble is, although the applications handle a real business need, they are
very badly designed because they are designed by non-programmers. Most IT
people have never been exposed to a well-written Access application, and are
consequently unaware that it can be done.
Also, it is quite possible for an application to start out in MS Accessm and
outgrow Access' capabilities. Management is always reluctant to pay for a
rewrite of a marginally working application, so the app tends to grow until it
eats fast amounts of IT resources to maintain because it's doing stuff it's
not designed to handle.
In short - Access tends to amplify management problems that adversely impact
IT.
There is another factor too. Expensive programmers who work in languages like
Smalltalk (an admittedly really nice language) tend not to want to compete for
their jobs and salary with application development that can be done part-time
by a bookeeper with no help from IT.
Jeffrey,
I saw your reference to $1500/Day Access Developers. I have built many
complete applications for less than $1500. If you are ever looking for
reasonably priced Access help, contact me.
--
PC Datasheet
Your Resource For Help With Access, Excel And Word Applications re******@pcdatasheet.com www.pcdatasheet.com
"Jeffrey P via AccessMonster.com" <u12062@uwe> wrote in message
news:54f7c3eb21c90@uwe... Our IT guys are on a vendetta against MS Access (and Lotus Notes but
they've
won that fight). What I can't understand is, what's the problem? Why
does
IT hate MS Access so much.
I have tried to find out who it is that actually wants to get rid of it,
but
I can't find anyone who will admit to trying to get rid of it.
Nevertheless,
I'm always hearing about how their "phasing it out" or "getting rid of
it".
Because no-one owns up I can't even have an open debate about the pros and
cons of MS Access.
It is certainly amazing what disinformation is out there about what
MS-Access
can and can't do. "MS Access clogs up the network". Well yeah... when IT
forces you to install the client of your client server app on the Network
Server it does. How come IT developer's clients can reside on the PC, but
a
non-IT developer's client can't? "MS-Access requires you to download a
copy
of the data before you can create a management report". Well no, we have
a
thing called ODBC. "MS-Access doesn't let you set up views/derived
tables/abstraction layer/ multi-dimensional cubes blah, blah, blah" Well,
actually,... it does! "MS-Access can't publish reports to the web" Wrong!
"You can't upgrade Access 95/97 apps to Access 2000/2003/XP". Bzzzt!
Wrong
again!
Meanwhile MS-Access has a number of exceptional strengths (a) an (almost)
comprehensive SDK (b) its cheap (c) lots of people have skills in it (no
$1500/day for an MS Access developer) (d) its well integrated with a
spreadsheet, a wordprocessor and its operating system (e) it's context
sensitive help is nothing short of fabulous (f) it has few limitations
with
regard to aggregating aggregates or filtering by aggregates, maintaining
previously calculated data, etc etc. Look I could go on, but I have no
forum to argue my case.
So what is it? Is it the security model of Access? Is it the fear that
IT
will be left holding the undocumented spaghetti-coded baby when the non-IT
developer skips town? Is it just that it's Microsoft, and its cool to
thumb
your nose at Bill Gates? Or is it that IT doesn't like non-IT people
having
access to the VB coding environment which can be used to overcome PC and
possibly Network security? Or is it something else?
I used to be in charge of Oracle DBAs and have been responsible for an
organisation's data management policy. I had nothing against MS Access
then.
So what's the deal?
Regards,
Jeff Popova-Clark
Gold Coast Australia
--
Message posted via AccessMonster.com
http://www.accessmonster.com/Uwe/For...ccess/200509/1
On Tue, 27 Sep 2005 01:46:33 GMT, "PC Datasheet" <no****@nospam.spam>
wrote:
Uh-oh. Batten down those hatches, folks.
mike
"Jeffrey P via AccessMonster.com" <u12062@uwe> wrote in message
news:54f7c3eb21c90@uwe... Our IT guys are on a vendetta against MS Access (and Lotus Notes but
they've
won that fight). What I can't understand is, what's the problem? Why
does
IT hate MS Access so much.
I have tried to find out who it is that actually wants to get rid of it,
but
I can't find anyone who will admit to trying to get rid of it.
Nevertheless,
I'm always hearing about how their "phasing it out" or "getting rid of
it".
Because no-one owns up I can't even have an open debate about the pros and
cons of MS Access.
It is certainly amazing what disinformation is out there about what
MS-Access
can and can't do. "MS Access clogs up the network". Well yeah... when IT
forces you to install the client of your client server app on the Network
Server it does. How come IT developer's clients can reside on the PC, but
a
non-IT developer's client can't? "MS-Access requires you to download a
copy
of the data before you can create a management report". Well no, we have
a
thing called ODBC. "MS-Access doesn't let you set up views/derived
tables/abstraction layer/ multi-dimensional cubes blah, blah, blah" Well,
actually,... it does! "MS-Access can't publish reports to the web" Wrong!
"You can't upgrade Access 95/97 apps to Access 2000/2003/XP". Bzzzt!
Wrong
again!
Meanwhile MS-Access has a number of exceptional strengths (a) an (almost)
comprehensive SDK (b) its cheap (c) lots of people have skills in it (no
$1500/day for an MS Access developer) (d) its well integrated with a
spreadsheet, a wordprocessor and its operating system (e) it's context
sensitive help is nothing short of fabulous (f) it has few limitations
with
regard to aggregating aggregates or filtering by aggregates, maintaining
previously calculated data, etc etc. Look I could go on, but I have no
forum to argue my case.
So what is it? Is it the security model of Access? Is it the fear that
IT
will be left holding the undocumented spaghetti-coded baby when the non-IT
developer skips town? Is it just that it's Microsoft, and its cool to
thumb
your nose at Bill Gates? Or is it that IT doesn't like non-IT people
having
access to the VB coding environment which can be used to overcome PC and
possibly Network security? Or is it something else?
I used to be in charge of Oracle DBAs and have been responsible for an
organisation's data management policy. I had nothing against MS Access
then.
So what's the deal?
Regards,
Jeff Popova-Clark
Gold Coast Australia
--
Message posted via AccessMonster.com
http://www.accessmonster.com/Uwe/For...ccess/200509/1
PC Datasheet wrote: Jeffrey,
I saw your reference to $1500/Day Access Developers. I have built many
complete applications for less than $1500.
You have a reading comprehension problem.
"rkc" <rk*@rochester.yabba.dabba.do.rr.bomb> wrote in message
news:74*******************@twister.nyroc.rr.com... PC Datasheet wrote: Jeffrey,
I saw your reference to $1500/Day Access Developers. I have built many
complete applications for less than $1500.
You have a reading comprehension problem.
That, and a penchant for spamming this ng.
I find some IT folks really don't know Access. Keep in mind it is a
desktop db. Not really a server application like Oracle or SQL. Also
notice that a lot of time IT folks are responsible for IT applications.
Access brings a lot of power to the hands of the users.
> I used to be in charge of Oracle DBAs and have been responsible for an organisation's data management policy. I had nothing against MS Access
then.
So what's the deal?
I think it's more of a control thing than the merits of Access. No one
wants to be responsible for something they have no control over. I remember
working for a mutual fund where we had to decipher a poorly-written Access
2.0 app with macros from hell. The pain and suffering of that kind of thing
results in company policy that forbids installation of Access on any
desktop.
Because VBA is easy to learn and Access has a built-in IDE, the department
that needs the solution (as opposed to the IT department) can have control
over the application - and avoid lengthy meetings, written requirements and
all the red tape and arguments over what the app should and should not do.
I finished a project in August for a company where the IT department hated
Access. My partner would go in and listen to the user's needs, let them
wave their arms, mumble a few things and then come to me with some vague
ideas about what they wanted. I ginned it up in a couple of days. The
customer was impressed with the ease of doing business with us - no project
plan, no written requirements, no formal meetings. I ended up writing
several iterations (each one wildly different from the last) because they
never really knew what they wanted. This was a good example of XP more than
the advantages of Access. But the RAD capabilities of Access allowed us to
deliver. If I was better acquainted with .NET I could have (perhaps would
have) written it in C# - and gotten the same contempt from the IT
department.
On Mon, 26 Sep 2005 20:45:24 -0700, "deko" <de**@nospam.com> wrote:
.... I finished a project in August for a company where the IT department hated
Access. My partner would go in and listen to the user's needs, let them
wave their arms, mumble a few things and then come to me with some vague
ideas about what they wanted. I ginned it up in a couple of days. The
customer was impressed with the ease of doing business with us - no project
plan, no written requirements, no formal meetings. I ended up writing
several iterations (each one wildly different from the last) because they
never really knew what they wanted. This was a good example of XP more than
the advantages of Access. But the RAD capabilities of Access allowed us to
deliver. If I was better acquainted with .NET I could have (perhaps would
have) written it in C# - and gotten the same contempt from the IT
department.
Note that if you are doing a good job with the XP process, when you're done
with an iteration, the customer does have a written set of requirements for
the product that evolved. The requirements are in the form of "Acceptance
Tests". Later, if someone needs to know what the code is supposed to do
before trying to fix a bug or change the "spec", they can start by looking
there.
Some handy tricks for simulating users from code in Access:
- To simulate user data entry in a control with events firing, move the focus
to the control, and update the control's .Text property.
- To handle message boxes in automated tests, write your own public MsgBox
function to override the built-in function, or just always call a custom
notification procedure such as AppMsgBox instead of using the built-in
function. You can use global variables to pre-set responses to dialogs right
before the actino that should bring them up, etc.
Steve,
Sounds like their blaming the guns instead of the gunslingers. Maybe we
should ban cars because some people drink drive or maybe we should ban arms
and hands because some people punch others with them.
We have dozens of badly written Access apps that are still chugging away
achieving their business requirements after years of waiting for an
enterprise wide all-bells/all-whistles solution to replace them. Of these
dozens I've never seen any get handed to IT (fair enough too). So they seem
to be afraid of a bogey that doesn't actually occur.
Besides the IT guys seem to miss the difference between XP/RAD and management
reporting. They want to throw out the baby with the bath water. I've seen
my employers spend very high sums putting in specialist mgt reporting apps
that require very costly developers to produce pretty simple reports that
could be done in Access in minutes.
To the second poster. I'm sorry for the confusion but I meant that no Access
developers get $1500/day unlike some Actuate, BusinessObjects and
MicroStrategy developers.
Regards,
Jeff Popova-Clark
Gold Coast, Australia
Steve Jorgensen wrote:
MS Access gives non-programmers the ability to create applications that become
indispensible to an organization and then must be maintained by IT. The
trouble is, although the applications handle a real business need, they are
very badly designed because they are designed by non-programmers. Most IT
people have never been exposed to a well-written Access application, and are
consequently unaware that it can be done.
Also, it is quite possible for an application to start out in MS Accessm and
outgrow Access' capabilities. Management is always reluctant to pay for a
rewrite of a marginally working application, so the app tends to grow until it
eats fast amounts of IT resources to maintain because it's doing stuff it's
not designed to handle.
In short - Access tends to amplify management problems that adversely impact
IT.
There is another factor too. Expensive programmers who work in languages like
Smalltalk (an admittedly really nice language) tend not to want to compete for
their jobs and salary with application development that can be done part-time
by a bookeeper with no help from IT.
--
Message posted via http://www.accessmonster.com
"Steve Jorgensen" <no****@nospam.nospam> wrote MS Access gives non-programmers the ability to create applications that
become
indispensible to an organization and then must be maintained by IT. The
trouble is, although the applications handle a real business need, they
are
very badly designed because they are designed by non-programmers. Most IT
people have never been exposed to a well-written Access application, and
are
consequently unaware that it can be done.
Also, it is quite possible for an application to start out in MS Accessm
and
outgrow Access' capabilities. Management is always reluctant to pay for a
rewrite of a marginally working application, so the app tends to grow
until it
eats fast amounts of IT resources to maintain because it's doing stuff
it's
not designed to handle.
Very well put.
--
Darryl Kerkeslager
On Tue, 27 Sep 2005 00:15:41 -0400, "Darryl Kerkeslager"
<ke*********@comcast.net> wrote: "Steve Jorgensen" <no****@nospam.nospam> wrote MS Access gives non-programmers the ability to create applications that
become
indispensible to an organization and then must be maintained by IT. The
trouble is, although the applications handle a real business need, they
are
very badly designed because they are designed by non-programmers. Most IT
people have never been exposed to a well-written Access application, and
are
consequently unaware that it can be done.
Also, it is quite possible for an application to start out in MS Accessm
and
outgrow Access' capabilities. Management is always reluctant to pay for a
rewrite of a marginally working application, so the app tends to grow
until it
eats fast amounts of IT resources to maintain because it's doing stuff
it's
not designed to handle.
Very well put.
But poorly typed <g>
Jeffrey P via AccessMonster.com wrote: Our IT guys are on a vendetta against MS Access (and Lotus Notes but they've
won that fight). What I can't understand is, what's the problem? Why does
IT hate MS Access so much.
I have tried to find out who it is that actually wants to get rid of it, but
I can't find anyone who will admit to trying to get rid of it. Nevertheless,
I'm always hearing about how their "phasing it out" or "getting rid of it".
Because no-one owns up I can't even have an open debate about the pros and
cons of MS Access.
It is certainly amazing what disinformation is out there about what MS-Access
can and can't do. "MS Access clogs up the network". Well yeah... when IT
forces you to install the client of your client server app on the Network
Server it does. How come IT developer's clients can reside on the PC, but a
non-IT developer's client can't? "MS-Access requires you to download a copy
of the data before you can create a management report". Well no, we have a
thing called ODBC. "MS-Access doesn't let you set up views/derived
tables/abstraction layer/ multi-dimensional cubes blah, blah, blah" Well,
actually,... it does! "MS-Access can't publish reports to the web" Wrong!
"You can't upgrade Access 95/97 apps to Access 2000/2003/XP". Bzzzt! Wrong
again!
Meanwhile MS-Access has a number of exceptional strengths (a) an (almost)
comprehensive SDK (b) its cheap (c) lots of people have skills in it (no
$1500/day for an MS Access developer) (d) its well integrated with a
spreadsheet, a wordprocessor and its operating system (e) it's context
sensitive help is nothing short of fabulous (f) it has few limitations with
regard to aggregating aggregates or filtering by aggregates, maintaining
previously calculated data, etc etc. Look I could go on, but I have no
forum to argue my case.
So what is it? Is it the security model of Access? Is it the fear that IT
will be left holding the undocumented spaghetti-coded baby when the non-IT
developer skips town? Is it just that it's Microsoft, and its cool to thumb
your nose at Bill Gates? Or is it that IT doesn't like non-IT people having
access to the VB coding environment which can be used to overcome PC and
possibly Network security? Or is it something else?
I used to be in charge of Oracle DBAs and have been responsible for an
organisation's data management policy. I had nothing against MS Access then.
So what's the deal?
Regards,
Jeff Popova-Clark
Gold Coast Australia
--
Message posted via AccessMonster.com
http://www.accessmonster.com/Uwe/For...ccess/200509/1
Microsoft has perpetuated the vendetta as much as anyone else. Let me
explain. Microsoft never wanted Access to be so good that SQL Server
would never be needed. They have to walk the line between pushing
Access and pushing SQL Server at the expense of Access. At $25,000 per
processor for the enterprise version of SQL Server 2005, guess which
back end is being pushed by Microsoft (I didn't mean it to sound like
that)? They've heard what SQL Server is going to be able to do. It
explains the "phasing it out" and "getting rid of it" along with
"abstraction layer" and "publish reports to the web" comments. Even
the security comments fall right into the line of fire of Microsoft's
advertising. The comments are exactly what Microsoft wants to hear. I
was even getting a little excited about the new capabilities. Maybe
SQL Server is going to be so good that no one will want to program in
Access anymore. They've done a lot to make the transition easier for
Access programmers. The CreateAssembly ability of SQL Server 2005 is
supposed to make it easy for it to include .NET functions created from,
say, Visual Studio similar to the way Access queries call public VBA
functions. I was told a few days ago by Mr. Shelton from Microsoft
that the Express edition would allow me to have 60 Access users hooked
up to it at no cost. The express version just doesn't have some
advanced features that I probably won't need anytime soon. He also
said the eight simultaneous connection limit of MSDE could probably
handle 50 users because of when the connections are needed. If more
than eight simultaneous connections are requested it will simply slow
things down temporarily. The huge effort to ease the transition shows
that Microsoft is pushing SQL Server very hard. For my situation SQL
Server at any price is not going to be anywhere near as convenient as
Access but I can easily imagine situations where SQL Server will be the
best solution. Plus, I'll be relying on this NG to help me find out
where the real headaches lie.
James A. Fortune
"Jeffrey P via AccessMonster.com" <u12062@uwe> wrote in message
news:54f7c3eb21c90@uwe... Our IT guys are on a vendetta against MS Access (and Lotus Notes but
they've won that fight). What I can't understand is, what's the problem? Why
does IT hate MS Access so much.
I have tried to find out who it is that actually wants to get rid of it,
but I can't find anyone who will admit to trying to get rid of it.
Nevertheless, I'm always hearing about how their "phasing it out" or "getting rid of
it". Because no-one owns up I can't even have an open debate about the pros and
cons of MS Access.
It is certainly amazing what disinformation is out there about what
MS-Access can and can't do. "MS Access clogs up the network". Well yeah... when IT
forces you to install the client of your client server app on the Network
Server it does. How come IT developer's clients can reside on the PC, but
a non-IT developer's client can't? "MS-Access requires you to download a
copy of the data before you can create a management report". Well no, we have
a thing called ODBC. "MS-Access doesn't let you set up views/derived
tables/abstraction layer/ multi-dimensional cubes blah, blah, blah" Well,
actually,... it does! "MS-Access can't publish reports to the web" Wrong!
"You can't upgrade Access 95/97 apps to Access 2000/2003/XP". Bzzzt!
Wrong again!
Meanwhile MS-Access has a number of exceptional strengths (a) an (almost)
comprehensive SDK (b) its cheap (c) lots of people have skills in it (no
$1500/day for an MS Access developer) (d) its well integrated with a
spreadsheet, a wordprocessor and its operating system (e) it's context
sensitive help is nothing short of fabulous (f) it has few limitations
with regard to aggregating aggregates or filtering by aggregates, maintaining
previously calculated data, etc etc. Look I could go on, but I have no
forum to argue my case.
So what is it? Is it the security model of Access? Is it the fear that
IT will be left holding the undocumented spaghetti-coded baby when the non-IT
developer skips town? Is it just that it's Microsoft, and its cool to
thumb your nose at Bill Gates? Or is it that IT doesn't like non-IT people
having access to the VB coding environment which can be used to overcome PC and
possibly Network security? Or is it something else?
I used to be in charge of Oracle DBAs and have been responsible for an
organisation's data management policy. I had nothing against MS Access
then. So what's the deal?
Regards,
Jeff Popova-Clark
Gold Coast Australia
--
Message posted via AccessMonster.com
http://www.accessmonster.com/Uwe/For...ccess/200509/1
They love what they know, and they hate what they don't know. Those with
expertise in, say, C++ will hate Visual Basic, and vice versa. It's
basically ignorance and fear, and the ultimate losers are always the people
paying the bills.
Jeffrey P via AccessMonster.com wrote: Our IT guys are on a vendetta against MS Access (and Lotus Notes but they've
won that fight). What I can't understand is, what's the problem? Why does
IT hate MS Access so much.
My experience is perhaps different, but in our organization "IT guys"
mean the network admins. Network admins have their own area of
expertise (for which I am eternally grateful) but unless they have a
development/DB background from previous experience, database
applications are usually *NOT* it. I doubt very much you're in the
category I'm about describe, given your background with Oracle, but many
people seem to think "IT" means everything.
Anyway, I find typically the network admins and PC support people like
to trash anything Microsoft.
--
Tim http://www.ucs.mun.ca/~tmarshal/
^o<
/#) "Burp-beep, burp-beep, burp-beep?" - Quaker Jake
/^^ "Whatcha doin?" - Ditto "TIM-MAY!!" - Me
Per Jeffrey P via AccessMonster.com: What I can't understand is, what's the problem? Why does
IT hate MS Access so much.
1) It's not a "real* development tool in their eyes. All their code management
and elevation tools are built around the source code/compiled executable
paradigm. Therefore it doesn't fit in their scheme of doing things, raising
the PITA factor substantially.
2) IT has a bias towards the fewest possible development tools. Fewer tools
mean greater fungibility of IT employees. Every so often, somebody in IT even
comes up with "We're gonna use just ONE tool in this shop...".
3) Since just about anybody can develop an MS Access app, just about anybody
does. IT's problem is that, in the end, they can get stuck maintaining the
final product.
4) Generally, IT people do not under the distinction between an MS Access front
end and a back end .MDB. Consequently they attribute all the
failings/shortcomings of a desktop DB to an MS Access front end (which could be
pointed at just about any client-server DB product.... but they don't know that)
5) Similar to #4, they don't think in terms of separate front end/back end for
MS Access. They've seen all these apps where the data and the front end are
commingled and that's their image of an MS Access app.
6) Access front ends *do* become corrupted - especially if somebody deploys them
by having multiple users open the same front end over a LAN connection. If
that corruption brings down a mission-critical application, that's just not
acceptable. Proper deployment of an MS Access app involves copying it down to
the user's workstation as needed. IT doesn't do things that way. They're
oriented towards install procs. Once again, MS Access apps don't fit the mold.
7) IT guys want the latest-and-greatest; both for the sake of interest and
career development.
8) You can't develop a real web-centric app with MS Access and web-centric is
hot right now.
9) You can't do an XML-based app with MS Access (well, maybe you could - I don't
really know, but nobody in their right mind is going to...)
10) Short delivery time is largely moot to most IT people. They want the app
done right. They're typically inundated with more work than they can handle
anyhow - so losing a job because they can't churn it out overnight doesn't hurt;
they're up to their eyeballs in work already.
11) Minimal development cost is largely moot to most IT people. Initial
development is only part of a project's lifetime cost. Maintenance and add-on
development have to be considered.
Having said all of the above, my biggest delivered project to date was a bond
trading system that I wound up billing about $225,000 for over a period of five
years.
Release 1.0 delivery was within six months of the project's inception. All the
rest was add-ons.
As of today, that system has been up and running for over 7 years.
It is scheduled to be replaced by an IT project Sometime Real Soon. Last time
I checked, they had spent *over* 23 million dollars on that project.
Yes, the new system has more functionality than mine does.... at least 40%,
maybe even double.
Does the user care? No. They were dragged kicking and screaming into the new
project.
--
PeteCresswell
Per deko: I finished a project in August for a company where the IT department hated
Access. My partner would go in and listen to the user's needs, let them
wave their arms, mumble a few things and then come to me with some vague
ideas about what they wanted. I ginned it up in a couple of days. The
customer was impressed with the ease of doing business with us - no project
plan, no written requirements, no formal meetings. I ended up writing
several iterations (each one wildly different from the last) because they
never really knew what they wanted. This was a good example of XP more than
the advantages of Access. But the RAD capabilities of Access allowed us to
deliver. If I was better acquainted with .NET I could have (perhaps would
have) written it in C# - and gotten the same contempt from the IT
department.
That's the basis of much of my business. In the words of a colleague, "I don't
sell programming, I sell happiness.".
My guys are typically high pressure types who are on one sort of treadmill or
another. The treadmill never stops and if they falter, they're dead. They
don't have the time or inclination to think deeply about what they want or to go
to a lot of meetings. Also, their environment is fluid. If circumstances
change, they need the requisite changes tomorrow...not next year.
My skill is to figure out what they *really* want and deliver it in iterative
stages - managing the design so it can cope with many possible changes.
--
PeteCresswell
In message <iK********************@comcast.com>, deko <de**@nospam.com>
writes I used to be in charge of Oracle DBAs and have been responsible for an
organisation's data management policy. I had nothing against MS Access
then.
So what's the deal?
I think it's more of a control thing than the merits of Access. No one
wants to be responsible for something they have no control over. I remember
working for a mutual fund where we had to decipher a poorly-written Access
2.0 app with macros from hell. The pain and suffering of that kind of thing
results in company policy that forbids installation of Access on any
desktop.
There's a new aspect to the problem of IT departments getting landed
with the job of maintaining an undocumented app written in an unfamiliar
language by a badly-trained programmer who left the company five years
ago. The new aspect is regulatory compliance.
I've seen places where users are forbidden from writing spreadsheet
macros because the auditors have objected. That sort of problem is
spreading to other companies because of new legislation.
As an IT Manager I'm quite prepared to have user departments design
applications in Access, it's a great tool. But they have to understand
that if there's an issue of support or regulatory compliance the buck
doesn't stop here unless I've signed off the work. If I'm going to do
that then I probably require all of that tedious documentation, and I
expect to see thoroughly documented code too.
My advice to IT Managers is to get a policy decision from the board on
how to handle future support issues long before the brown and smelly
hits the fan.
--
Bernard Peek
London, UK. DBA, Manager, Trainer & Author.
"Randy Harris" <ra***@SpamFree.com> wrote in
news:kc***************@newssvr23.news.prodigy.net:
"rkc" <rk*@rochester.yabba.dabba.do.rr.bomb> wrote in message
news:74*******************@twister.nyroc.rr.com... PC Datasheet wrote: > Jeffrey,
>
> I saw your reference to $1500/Day Access Developers. I have
> built many complete applications for less than $1500.
You have a reading comprehension problem.
That, and a penchant for spamming this ng.
If y'all had ignored his post, there would be 3 fewer (now 4) posts
in the newsgroup, none of which serve any useful purpose whatsoever.
Hold your tongues and the problem will cease to exist. If I can do
it with the personal attacks of Don Mellon, you can do it with
Steve.
--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
"Dean" <de**@coveyaccounting.com> wrote in
news:11**********************@z14g2000cwz.googlegr oups.com: I find some IT folks really don't know Access. Keep in mind it is
a desktop db. Not really a server application like Oracle or SQL.
Also notice that a lot of time IT folks are responsible for IT
applications.
Access brings a lot of power to the hands of the users.
I think this is the key point. They don't understand several things:
1. that Access is both a database (Jet) and a development
environment
2. that 1) means that Access can be used as a front end development
system to non-Jet back ends (a whole host of them, in fact, and more
than any other front end that I've ever heard of).
3. that storing your back end data in Jet is not nearly as
inefficient as the imagine, if the schema is properly designed and
has judicious and correct use of indexes. Many of them never get
past the erroneous idea that Access pulls the entire MDB file across
the network, instead of pulling header data, then indexes and then
only those pages that are necessary for a particular task. Part of
the reason for this is that most of the sample databases that come
with Access sre extremely poorly designed, with forms and reports
bound to full tables, instead of being appropriately filtered.
4. that Jet is actually a remarkably intelligent manager for getting
to ODBC data. Most of them that know Jet is involved think that Jet
makes the data retrieval inefficient. But it's actually precisely
the opposite -- Jet is very smart about processing local queries and
recordsources and sending to the server a request for the minimal
amount of data. Of course, in some cases, Jet guesses wrong, or the
data request cannot be made efficient (because it's badly designed).
In those cases, the answer is to redesign the offending data
request, either to use server-side views or stored procedures (where
that's appropriate) to either replace the original Access SQL, or to
create server-side views that will make it possible to write
substantially more efficient Access SQL.
Well, that's some of them.
Most of them just don't know enough about Access to understand it.
Access actually substantially deeper and more complex than most
people have any idea about and it takes quite a bit of work to
educate them about what Access can do in the different contexts in
which it can be used. But that also requires someone who is really
knowledgable of the ins and outs of how to use Access best for each
of the specific tasks involved.
--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
"(PeteCresswell)" <a@b.c.invalid.USA> wrote in
news:lt********************************@4ax.com: My guys are typically high pressure types who are on one sort of
treadmill or another. The treadmill never stops and if they
falter, they're dead. They don't have the time or inclination to
think deeply about what they want or to go to a lot of meetings.
Also, their environment is fluid. If circumstances change, they
need the requisite changes tomorrow...not next year.
My skill is to figure out what they *really* want and deliver it
in iterative stages - managing the design so it can cope with many
possible changes.
Well, my experience is that it's hard to tell the difference on the
front end between the ones who are going to give you consistent
instructions and the ones who are just flailing around.
About 1/3 of the projects I've taken on have been failed development
projects because before the application was completed, one of these
things happened:
1. management changed that the original team that wanted it is no
longer interested in finishing it.
2. there was no real commitment to the application in the first
place, and though they nodded their heads knowingly when I told them
it would be an iterative process requiring a repeating cycle of them
giving feedback on the drafts I bring them, what they really expect
is for me to go away from the initial meeting and come back with a
finished app that does everything they wanted (and everythign they
hadn't yet thought about). Once they realize it requires significant
time for them to work on these evaluations of the drafts, they lose
interest.
3. they want to micromanage the development process. They can't
write a spec, they can't tell you precisely what they want, but THEY
KNOW IT WHEN THEY SEE IT. And that usually means they know they
don't like it. "Can't you make that work the way Outlook does it?"
Well, no, because Outlook is presenting a completely different kind
of data. Or, yes, I can do that, but it would misrepresent the
underlying data, and confuse the users with a UI structure that is
so far from the actual underlying data structure that it may make it
impossible for them to understand the consequences of their edits.
Or it might be extremely slow. Etc., etc., etc. Then there's "well,
can it be *blue*?" Yes, of course. At the next meeting: "Ick! I hate
that blue color!" But that's exactly what you asked for, an it's the
exact shade of blue that you approved looking at this monitor
connected to this exact same computer. "Well, you should have told
me that it wouldn't look good!" And so forth.
In general, what you need when a project is done without firm specs
is a liaison at the client who is every smart and who is willing to
devote the time to working with the developer to make the decisions
that the developer cannot make on her own. I've had way too many
projects that were contracted at 6 weeks drag out to 6 months
because the client would never respond to requests for
feedback/testing.
The projects where I've had one or more of these smart liaisons have
been the most rewarding of my Access development career. Not only
has the process been enjoyable (and profitable), but the results
have almost always been really impressive, both cosmetically and
functionally.
But it really does take a big commitment from the client -- no
developer can create the "happiness" you aim for in the absence of
clear direction at all the decision points that pop up in the
process.
--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
Pete,
Thankyou for your insightful response. I believe you'd agree that there's no
good reasons and all of them are about its XP/RAD capability and not its
management reporting capability. Also most of the "issues" are regarding its
misuse rather than the product itself. As I stated above, let's ban cars
because some of the drivers drive under the influence of alcohol.
You're case study on the bond trading system is also excellent. I will
certainly be quoting it around the traps.
Regards,
Jeff Popova-Clark
Gold Coast, Australia
(PeteCresswell) wrote: Per Jeffrey P via AccessMonster.com: What I can't understand is, what's the problem? Why does
IT hate MS Access so much.
[Excellent summary of reasons why IT hates Access}
Having said all of the above, my biggest delivered project to date was a bond
trading system that I wound up billing about $225,000 for over a period of five
years.
Release 1.0 delivery was within six months of the project's inception. All the
rest was add-ons.
As of today, that system has been up and running for over 7 years.
It is scheduled to be replaced by an IT project Sometime Real Soon. Last time
I checked, they had spent *over* 23 million dollars on that project.
Yes, the new system has more functionality than mine does.... at least 40%,
maybe even double.
Does the user care? No. They were dragged kicking and screaming into the new
project.
--
Message posted via http://www.accessmonster.com
David W. Fenton wrote: "Dean" <de**@coveyaccounting.com> wrote in
news:11**********************@z14g2000cwz.googlegr oups.com:
I find some IT folks really don't know Access. Keep in mind it is
a desktop db. Not really a server application like Oracle or SQL.
Also notice that a lot of time IT folks are responsible for IT
applications.
Access brings a lot of power to the hands of the users.
I think this is the key point. They don't understand several things:
1. that Access is both a database (Jet) and a development
environment
2. that 1) means that Access can be used as a front end development
system to non-Jet back ends (a whole host of them, in fact, and more
than any other front end that I've ever heard of).
3. that storing your back end data in Jet is not nearly as
inefficient as the imagine, if the schema is properly designed and
has judicious and correct use of indexes. Many of them never get
past the erroneous idea that Access pulls the entire MDB file across
the network, instead of pulling header data, then indexes and then
only those pages that are necessary for a particular task. Part of
the reason for this is that most of the sample databases that come
with Access sre extremely poorly designed, with forms and reports
bound to full tables, instead of being appropriately filtered.
4. that Jet is actually a remarkably intelligent manager for getting
to ODBC data. Most of them that know Jet is involved think that Jet
makes the data retrieval inefficient. But it's actually precisely
the opposite -- Jet is very smart about processing local queries and
recordsources and sending to the server a request for the minimal
amount of data. Of course, in some cases, Jet guesses wrong, or the
data request cannot be made efficient (because it's badly designed).
In those cases, the answer is to redesign the offending data
request, either to use server-side views or stored procedures (where
that's appropriate) to either replace the original Access SQL, or to
create server-side views that will make it possible to write
substantially more efficient Access SQL.
Well, that's some of them.
Most of them just don't know enough about Access to understand it.
Access actually substantially deeper and more complex than most
people have any idea about and it takes quite a bit of work to
educate them about what Access can do in the different contexts in
which it can be used. But that also requires someone who is really
knowledgable of the ins and outs of how to use Access best for each
of the specific tasks involved.
Well said. I've been fighting IT people off and on for years about using
Access as a dbms, and/or a development environment.
In 2002 an IT guy at the client fought with me about building a big system
in Access; he said "I can tell you that ALL of them were converted to VB or
VC at some point in time due to a whole host of issues; especially in a
multiuser environment using SQL Server. MS-Access is good IIF you use
native access tables/data and structures AND you have less than 5 users
concurrent. You can proceed on your current path, but I suspect that some
time in the future, we will convert this UI to something else.."
That was over 3 years ago. Since then, the system (Access 2000, 10-12 user,
SQL Server backend) has performed admirably, was never converted, and was
recently put into production use by Orbitz (travel).
I'm going to have to follow up with that guy - maybe even thumb my nose at
him a little...:)
David W. Fenton wrote: Hold your tongues and the problem will cease to exist. If I can do
it with the personal attacks of Don Mellon, you can do it with
Steve.
Years of similar posts by Steve contradict that statement.
The least he can do is try to appear intelligent while he
flips us all off.
Per Jeffrey P via AccessMonster.com: Thankyou for your insightful response. I believe you'd agree that there's no
good reasons
I'd say that the specter of database corruption is one of the 'good' reasons -
assuming somebody's using JET as the back end.
There's also one I missed re/deployment: You have the next release of MS Office
hanging over your head. Will the app be compatible with the next release?
Will the using company roll out the next release all at once or piecemeal?
Will the app open, but start popping annoying security-level notifications? None
of this is insurmountable, but must be considered in the deployment.
Beeeeg diff between managing the deployment of a couple thousand instances of a
compiled app via a proven install proc and a couple thousand instances of an MS
Access app that is dependent on the config of each user's MS Office.
Except for the corruption bit, all moot for a department-level app with less
than 20 users....
--
PeteCresswell
"Jeffrey P via AccessMonster.com" <u12062@uwe> wrote in message
news:54f7c3eb21c90@uwe... Why do IT guys hate MS Access?
That's easy. Access is gay and most IT guys are homophobic.
Jeffrey P via AccessMonster.com wrote: Steve,
Sounds like their blaming the guns instead of the gunslingers. Maybe we
should ban cars because some people drink drive or maybe we should ban arms
and hands because some people punch others with them.
We have dozens of badly written Access apps that are still chugging away
achieving their business requirements after years of waiting for an
enterprise wide all-bells/all-whistles solution to replace them. Of these
dozens I've never seen any get handed to IT (fair enough too). So they seem
to be afraid of a bogey that doesn't actually occur.
Besides the IT guys seem to miss the difference between XP/RAD and management
reporting. They want to throw out the baby with the bath water. I've seen
my employers spend very high sums putting in specialist mgt reporting apps
that require very costly developers to produce pretty simple reports that
could be done in Access in minutes.
To the second poster. I'm sorry for the confusion but I meant that no Access
developers get $1500/day unlike some Actuate, BusinessObjects and
MicroStrategy developers.
I do a lot of work for a large multinational company, in its Customer
Services division. In the good old days they had an in-house IT
department with a couple of general purpose bods, one of whom gained a
reputation as an Access "developer". So during his time there he
created a couple of dozen ad hoc applications to support little
business requirements.
Then there was one of those occasional management shake-ups. The
company adopted some very outre Japanese business methods, and the
in-house IT department became an in-house IT outsourcing operative.
This is where I came in - initially to develop an application that
would formerly have been developed by the now defunct Access
"developer". The company liked my work, so I created some more stuff
for them. I've no idea how they "saved" money, since I charged a hell
of a lot more than the guy they got rid of. And then, of couse, his
applications needed support, so I tendered for (and got) the contract
to support them.
What a mistake! Every single one was a crock. The "look and feel" was
as you'd expect of someone tinkering with Access out of the box, and
the code behind (where he'd used code behind, being a really BIG fan of
macros) was impossible to decipher. Of course, it didn't help that he
never discovered the Property page, so all controls retained their
default names.
The company are gradually putting all these apps. on their intranet, so
I'm now rewriting the old Access apps in .NET. Nice work.
Edward
Per te********@hotmail.com: I'm now rewriting the old Access apps in .NET.
What's your feel for the number of man hours to develop the same app in .NET vs
MS Access?
--
PeteCresswell
(PeteCresswell) wrote: Per te********@hotmail.com:I'm now rewriting the old Access apps in .NET.
What's your feel for the number of man hours to develop the same app in .NET vs
MS Access?
Using Windows forms, it's probably about 1.5 - 2 times as many man
hours. Of course, as you develop a good code library, this will
decrease;-) Luckily, there's a host of good resources for .NET
developers - Microsoft itself providing some key ideas.
Most of my current development is on web forms using ASP.NET and
VB.NET. Here, I find it takes around 2 -3 times as long to develop the
same or similar applications. The killers are a) the design of web
forms is incredibly time consuming and hacky, especially if you want to
use things like Tab controls, and b) reporting. Ah, Access, and its
unparalleled report designer. I'm more or less on top of Crystal
Reports and it has some neat features, but it's buggy and glass-jawed.
Edward
rkc <rk*@rochester.yabba.dabba.do.rr.bomb> wrote in
news:9A****************@twister.nyroc.rr.com: David W. Fenton wrote:
Hold your tongues and the problem will cease to exist. If I can
do it with the personal attacks of Don Mellon, you can do it with
Steve.
Years of similar posts by Steve contradict that statement.
The least he can do is try to appear intelligent while he
flips us all off.
The annoyance is all in *your* head. His posts don't bother me in
the slightest.
And I don't have him killfiled, either.
--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
> 6) Access front ends *do* become corrupted - especially if somebody deploys them by having multiple users open the same front end over
a LAN connection.
Pete: Can you elaborate on this point?
A lot of what my team does is ODBC grabs of AS/400 data for reporting
purposes, but we have a handful of "normal apps" out there as well.
Aside from the issues involved with closing a form that multiple people
may be resorting/filtering -- which can be bypassed in
DoCmd.Close...,acSaveNo -- but what "corruption" can occur beyond that?
The reason I ask is that we're currently embattled with our IT group
over putting Access (currently using 97, but there's "talk" over upping
to 2k3) on Terminal Server. The wars being fought over it yanking from
the pool as well as "Do we really want to stay with Access as a
development team for Your Group?" are fevered to say the least.
....loving this thread.
David W. Fenton wrote: rkc <rk*@rochester.yabba.dabba.do.rr.bomb> wrote in
news:9A****************@twister.nyroc.rr.com:
David W. Fenton wrote:
Hold your tongues and the problem will cease to exist. If I can
do it with the personal attacks of Don Mellon, you can do it with
Steve.
Years of similar posts by Steve contradict that statement.
The least he can do is try to appear intelligent while he
flips us all off.
The annoyance is all in *your* head. His posts don't bother me in
the slightest.
And I don't have him killfiled, either.
You don't read his posts.
You only showed up in this thread because Steve Jorgensen replied
to the op.
Per ac*******@railvan.com: 6) Access front ends *do* become corrupted - especially if somebody
deploys them by having multiple users open the same front end over
a LAN connection.
Pete: Can you elaborate on this point?
IMHO, the right way to deploy an MS Access front end is to have it copied down
to each user's PC. This limits corruption to a single installation of the
application - and makes corruption considerably less likely.
I use an icon pointed to a .Bat file for this purpose. The user clicks the
icon and the .Bat file checks to see if the latest version is on the user's PC
and copies it down if not. The .Bat file refers to a "Version.txt" file that
gives the name of the latest version number. To elevate a new version, I just
edit Version.txt. That text file also has a couple of parms in it - among
them is "ForceAppRefresh".... which I can set to "Yes" if I suspect a user's
version is corrupted.
This .Bat file is large, ugly, and quite intimidating. But it's also been
working for over 10 years with no problems and once somebody understands what is
where, it's reasonably easy to clone for another app/LAN.
I think greater minds than mine have come up with a compiled application that
does the same thing..... but I couldn't tell you where to find it. Maybe
somebody else can chime in.
--
PeteCresswell
rkc <rk*@rochester.yabba.dabba.do.rr.bomb> wrote in
news:Nv******************@twister.nyroc.rr.com: David W. Fenton wrote: rkc <rk*@rochester.yabba.dabba.do.rr.bomb> wrote in
news:9A****************@twister.nyroc.rr.com:
David W. Fenton wrote:
Hold your tongues and the problem will cease to exist. If I can
do it with the personal attacks of Don Mellon, you can do it
with Steve.
Years of similar posts by Steve contradict that statement.
The least he can do is try to appear intelligent while he
flips us all off.
The annoyance is all in *your* head. His posts don't bother me in
the slightest.
And I don't have him killfiled, either.
You don't read his posts.
I *do* read his posts, but only when they are in threads that I'm
interested in.
You only showed up in this thread because Steve Jorgensen replied
to the op.
That's right -- I wouldn't have seen the thread if someone on my
SELECT list had not posted in it (i.e., Steve J.).
You're the only one who can control your reaction to the posts that
annoy you -- the annoyance is purely in the eye of the beholder.
Complaining about it and scolding the person making the annoying
posts don't do much other than add more useless posts to the
newsgroup. Given that you accused Steve of "spamming" the newsgroup,
this is pretty ironic, as your complaints are causing more useless
posts than the offending poster.
--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
"ac*******@railvan.com" <ac*******@railvan.com> wrote in
news:11**********************@f14g2000cwb.googlegr oups.com: 6) Access front ends *do* become corrupted - especially if
somebody deploys them by having multiple users open the same
front end over a LAN connection.
Pete: Can you elaborate on this point?
A lot of what my team does is ODBC grabs of AS/400 data for
reporting purposes, but we have a handful of "normal apps" out
there as well. Aside from the issues involved with closing a form
that multiple people may be resorting/filtering -- which can be
bypassed in DoCmd.Close...,acSaveNo -- but what "corruption" can
occur beyond that?
The reason I ask is that we're currently embattled with our IT
group over putting Access (currently using 97, but there's "talk"
over upping to 2k3) on Terminal Server. The wars being fought
over it yanking from the pool as well as "Do we really want to
stay with Access as a development team for Your Group?" are
fevered to say the least.
A97 could survive multiple users opening the same MDB pretty well.
But A2K is much more fragile, because of the change to the
monolithic save model, where instead of each Access object (form,
report, etc.) being a record in a system table, the entire Access
project is stored as a BLOB in a single record in a system table.
This why in A97 you could edit forms or reports while other users
were in the database (as long as they weren't editing the same
object -- think of it in of record locking), whereas in A2K, only
one user at a time can edit objects, and if any other users already
have the database open, nobody can edit anything. It's because all
the objects are in a single record, so any object changing requires
a rewrite of the record's BLOB field (i.e., the entire Access
project).
Even in read-only mode, there are properties that get saved (whether
you want them to be or not) and these can cause write collisions in
the database record.
And that leads to significantly more front-end corruption problems
in a shared A2K front end MDB than in any previous version of
Access.
Terminal Server is a great way to roll out remote Access
applications, and you give each user a copy of the front end that is
stored in their user profile on the Terminal Server. A client of
mine implemented a brand new TS at the beginning of the year (to
support 2 Access apps and remote users of QuickBooks), and it cost
them just over $2,000 in hardware costs to put together a Compaq
rack server with lots of disk space an a couple of gigs of RAM. It
is a beautiful installation and makes administering these Access
applications truly easy.
Terminal Server deployment of Access apps vastly *reduces*
administrative costs. That should be a selling point.
--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
"(PeteCresswell)" <a@b.c.invalid.USA> wrote in
news:d7********************************@4ax.com: I think greater minds than mine have come up with a compiled
application that does the same thing..... but I couldn't tell you
where to find it. Maybe somebody else can chime in.
I'm not sure about the "greater minds" part, but the most commonly
mentioned such compiled utility is Tony Toews's: http://www.granite.ab.ca/access/autofe.htm
I've used it and I think it's great. It also supports a lot of
things that batch files simply can't do (such as executing the
appropriate version of Access, or being version-agnostic in an
environment where users don't all have the same version of Access).
--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
David W. Fenton wrote: Given that you accused Steve of "spamming" the newsgroup,
this is pretty ironic, as your complaints are causing more useless
posts than the offending poster.
I pointed out that he didn't understand what he read. Nothing more.
"(PeteCresswell)" <a@b.c.invalid.USA> wrote in message
news:d7********************************@4ax.com...
I've written a small VB app. Below is the complete code.
This is a VB app which updates a client version of an Access front end, if
there is a different version, probably on a server.
It takes 5 command line arguments, the 5th being optional, each preceded by
a /
C:\path\UpdateClient.exe - call the updater itself
/mydatabase.mdb - the client FE to be updated
/\\server\path to newversion.mdb - the update version to use
/\\server\path to mdw\xxx.mdw - the workgroup file
/mydatabase.ini - a simple text file that stores the last username used
/C:\Microsoft Office 2000\Office\msaccess.exe - the path to the Access
executable, optional
The last argument is optional, probably only of any use where there is more
than one version of Access on the machine, otherwise the default version of
Access is used.
UpdateClient.exe must be in the same directory as the file to be updated, as
must the ini file.
UpdateClient expects to find a table called mySysDbProperties with fields
called PropID, PropName, PropValue, Comments. This is a local table, NOT a
linked table, that needs to be in both versions of the client. There needs
to be a record with a value in the PropName of 'Version' and a corresponding
value, the actual version number, in PropValue. This is what gets compared.
All that is checked is a difference. Not a later version!
The only form in the app mimics the look of an Access login, hence the use
of the ini file to store the last logged on user. The desktop link the users
use to 'start' the database is to this VB app, not the actual MDB
It has worked rock solid so far. The only problem I've had is where I've
altered the mdw groups, so that the updater can't open the old file, because
permissions have changed.
I could probably parameterise it some more. Maybe making the table/columns
where the version number is stored arguments, rather than hard coding them
as it is at the moment.
I originally tried doing this using an mdb 'updater', but it was a mess.
Especially the permissions. And it was a great deal bigger than this
solution. Seems silly to open Access just to check one field in one table in
another mdb file.
Oh yes, and if it does find a new version it makes a backup of the old one,
with yyyymmddhhnn appended to the filename, in the workstation directory.
Comments welcome, Emily
**************************Code starts*********************************
Option Explicit
Private Sub cmdCancel_Click()
'TVCodeTools ErrorEnablerStart
On Error GoTo PROC_ERR
'TVCodeTools ErrorEnablerEnd
Unload Me
'TVCodeTools ErrorHandlerStart
PROC_EXIT:
Exit Sub
PROC_ERR:
MsgBox Err.Description
Resume PROC_EXIT
'TVCodeTools ErrorHandlerEnd
End Sub
Private Sub cmdOK_Click()
'TVCodeTools ErrorEnablerStart
On Error GoTo PROC_ERR
'TVCodeTools ErrorEnablerEnd
Dim dbWorkStationCopy As Database
Dim dbServerCopy As Database
Dim FullFrontEndPath As String
Dim rstFrontEndVersion As Recordset
Dim rstUpdateVersion As Recordset
Dim WorkStationVersion As String
Dim ServerVersion As String
Dim wrk As Workspace
Dim arrArgs As Variant
Dim fso As New FileSystemObject
Dim fil As File
Dim ts As TextStream
Dim strAccessPath As String
Dim filFE As File
arrArgs = GetCommandLine(5)
FullFrontEndPath = CurDir & "\" & arrArgs(1)
DBEngine.SystemDB = arrArgs(3)
Set wrk = DBEngine.CreateWorkspace("wrkTemp", Me.txtUserName,
Me.txtPassword)
Set dbWorkStationCopy = DBEngine(0).OpenDatabase(FullFrontEndPath)
Set rstFrontEndVersion =
dbWorkStationCopy.OpenRecordset("mySysDbProperties ", dbOpenSnapshot)
rstFrontEndVersion.FindFirst "PropName = 'Version'"
WorkStationVersion = rstFrontEndVersion.Fields("PropValue").Value
rstFrontEndVersion.Close
dbWorkStationCopy.Close
Set dbServerCopy = DBEngine(0).OpenDatabase(arrArgs(2))
Set rstUpdateVersion = dbServerCopy.OpenRecordset("mySysDbProperties",
dbOpenSnapshot)
rstUpdateVersion.FindFirst "PropName = 'Version'"
ServerVersion = rstUpdateVersion.Fields("PropValue").Value
rstUpdateVersion.Close
dbServerCopy.Close
DBEngine(0).Close
Set fil = fso.GetFile(arrArgs(4))
Set ts = fil.OpenAsTextStream(ForWriting, TristateUseDefault)
ts.Write (Me.txtUserName)
ts.Close
If WorkStationVersion <> ServerVersion Then
Set filFE = fso.GetFile(FullFrontEndPath)
filFE.Name = Format(Now, "yyyymmddHhNn") & "_" & filFE.Name
fso.CopyFile arrArgs(2), FullFrontEndPath, True
End If
If UBound(arrArgs) < 5 Then
strAccessPath = SysCmd(acSysCmdAccessDir) & "msaccess.exe"
'this above seems to be the only call that needs the Access object
library
'so maybe best to always supply the 5th argument, as the Access
object library
'is the only one which is likely to be in a non standard location.
'or make it late binding?
Else
strAccessPath = arrArgs(5)
End If
Shell strAccessPath & " " & FullFrontEndPath & " /wrkgrp " & arrArgs(3)
& _
"/user " & txtUserName & "/pwd " & txtPassword, vbMaximizedFocus
wrk.Close
Unload Me
'TVCodeTools ErrorHandlerStart
PROC_EXIT:
Exit Sub
Unload Me
PROC_ERR:
MsgBox Err.Description
Resume PROC_EXIT
'TVCodeTools ErrorHandlerEnd
End Sub
Private Sub Form_Load()
'TVCodeTools ErrorEnablerStart
On Error GoTo PROC_ERR
'TVCodeTools ErrorEnablerEnd
Dim fso As New FileSystemObject
Dim fil As File
Dim ts As TextStream
Dim arrArgs As Variant
arrArgs = GetCommandLine(5)
Set fil = fso.GetFile(arrArgs(4))
Set ts = fil.OpenAsTextStream(ForReading, TristateUseDefault)
Me.txtUserName = ts.ReadAll
Me.Show
Me.txtPassword.SetFocus
'TVCodeTools ErrorHandlerStart
PROC_EXIT:
Exit Sub
PROC_ERR:
MsgBox Err.Description
Resume PROC_EXIT
'TVCodeTools ErrorHandlerEnd
End Sub
**************************Code ends**********************************
"David W. Fenton" <dX********@bway.net.invalid> schreef in bericht news:Xn**********************************@216.196. 97.142... The annoyance is all in *your* head. His posts don't bother me in
the slightest.
And I don't have him killfiled, either.
David,
I did 'get' your message in another thread, but I really don't get this one.
The annoyance about Steve (an understatement IMO) is in a lot of heads around here.
And Steve will *not* stop his advertising and his abuse of the newsgroups if we ignore him.
He has proved that more than once over the years.
Arno R
In message <d7********************************@4ax.com>,
"(PeteCresswell)" <a@b.c.invalid.USA> writes This .Bat file is large, ugly, and quite intimidating. But it's also been
working for over 10 years with no problems and once somebody
understands what is
where, it's reasonably easy to clone for another app/LAN.
It's worth noting that Microsoft is revising the command-line shell for
the next version of Windows, the new version is currently in beta. If
anyone make a lot of use of batch files, or has one that is
business-critical, they might want to take a look at it. The new shell
is quite different to the MS-DOS emulator in current versions of
Windows.
--
Bernard Peek
London, UK. DBA, Manager, Trainer & Author.
On Thu, 29 Sep 2005 13:50:53 +0100, Bernard Peek <ba*@shrdlu.com> wrote: It's worth noting that Microsoft is revising the command-line shell for
the next version of Windows, the new version is currently in beta. If
anyone make a lot of use of batch files, or has one that is
business-critical, they might want to take a look at it. The new shell
is quite different to the MS-DOS emulator in current versions of
Windows.
Great.
Maybe this will be so powerful that it will end up being turned off like
WSH which was also supposed to replace the command shell.
Windows Script Host was turned off?
On 29 Sep 2005 07:40:39 -0700, "lylefair" <ly******@yahoo.ca> wrote: Windows Script Host was turned off?
No no I was carried away here, just that admins have severly restricted its context of use in many
cases so you can't rely on it.
"Arno R" <ar***********@tiscali.nl> wrote in
news:43********************@dreader2.news.tiscali. nl: "David W. Fenton" <dX********@bway.net.invalid> schreef in bericht
news:Xn**********************************@216.196. 97.142... The annoyance is all in *your* head. His posts don't bother me in
the slightest.
And I don't have him killfiled, either.
I did 'get' your message in another thread, but I really don't get
this one.
The annoyance about Steve (an understatement IMO) is in a lot of
heads around here. And Steve will *not* stop his advertising and
his abuse of the newsgroups if we ignore him. He has proved that
more than once over the years.
Then it's up to you to GET OVER IT.
If many of your posts end up being complaints about Steve, then
*you'll* be the one who ends up in the killfiles.
--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
Bernard Peek <ba*@shrdlu.com> wrote in
news:3+**************@shrdlu.com: In message <d7********************************@4ax.com>,
"(PeteCresswell)" <a@b.c.invalid.USA> writes
This .Bat file is large, ugly, and quite intimidating. But it's
also been working for over 10 years with no problems and once
somebody understands what is
where, it's reasonably easy to clone for another app/LAN.
It's worth noting that Microsoft is revising the command-line
shell for the next version of Windows, the new version is
currently in beta. If anyone make a lot of use of batch files, or
has one that is business-critical, they might want to take a look
at it. The new shell is quite different to the MS-DOS emulator in
current versions of Windows.
Are you suggesting that MS will make this new command shall
incompatible with legacy command scripts and batch files? I find
that suggestion to be massively implausible, as it would go against
MS's entire history of maintaining backward compatibility at all
costs.
MS can't afford to break literally trillions of batch and command
scripts that are already in existence out there.
They've done an excellent job of keeping the NT command prompt
compatible with the DOS command shell. I can't see that MS would add
new functionality in a way that would break the old.
--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
Per Bernard Peek: It's worth noting that Microsoft is revising the command-line shell for
the next version of Windows, the new version is currently in beta. If
anyone make a lot of use of batch files, or has one that is
business-critical, they might want to take a look at it. The new shell
is quite different to the MS-DOS emulator in current versions of
Windows.
Uh-Oh..... Thanks for the warning.
--
PeteCresswell
Per David W. Fenton: A97 could survive multiple users opening the same MDB pretty well.
Even with 97, you've got the dilemma of printer conflicts. Suppose user A
changes a report to go to printer #1, but user B can only get to printer #2?
--
PeteCresswell
"David W. Fenton" <dX********@bway.net.invalid> wrote in message
news:Xn**********************************@216.196. 97.142... MS's entire history of maintaining backward compatibility at all
costs.
Ha! Just ask the VB6 fraternity about that...
In message <Xn**********************************@216.196.97.1 42>, David
W. Fenton <dX********@bway.net.invalid> writes Are you suggesting that MS will make this new command shall
incompatible with legacy command scripts and batch files? I find
that suggestion to be massively implausible, as it would go against
MS's entire history of maintaining backward compatibility at all
costs.
MS can't afford to break literally trillions of batch and command
scripts that are already in existence out there.
I'd expect them to aim for complete compatibility but I don't expect
100% success. If your batch files are business critical then you really
need to check compatibility for yourself.
--
Bernard Peek
London, UK. DBA, Manager, Trainer & Author. This thread has been closed and replies have been disabled. Please start a new discussion. |
