web-accessing a database

OK, I've a project at work. We have a database around a table with
about 5,000 rows and 50 or so columns.

We have a stand-alone Access application that allows us to run various
reports and now want to offer this to a wider group of users across a
corporate intranet. We have access to a suitable networked machine
(dual xeon machine running XP pro) and the 'plan' was to use a web front
end to run the access application.

There would be in the region of about 70 remote users but we would not
expect more than, say, five concurrent users at any point in time.
Please note that these users would only have read access and would be
running pre-written reports to manipulate the data and would not be
writing their own reports.

The reason for having the data in one place is to avoid the risk that
the users do not update the data and are using out of date information;
having a central data repository under my direct control allows me to be
confident that I am offering the very best quality information that I
have.

However, one of the chaps in my team with a relatively strong 'IT'
background is now making statements that "It will never work, Access is
not up to the job it has flawed record locking" etc. etc. etc.

I am finding it very hard to understand whether this is a realistic
concern or whether the IT bod is looking for a job rewriting the
database application.

Can anyone offer any helpful, or failing that amusing, insights?

 

<hard to snip so I didn't bother - much>

Record locking shouldn't be an issue if the users are read only. I
don't think even Access blocks readers, although it's been many, many
years since I last did any Access development, so ICBW.

FWIW I wrote an ordering/invoicing system in Access for my parents'
company. There's one .mdb that just contains the data & sits on the
server, and a 'client' .mdb that just contains the forms/reports & sits
on each workstation. The client .mdbs connect to the data .mdb over the
network. If you could do the same over your intranet, it would save
having to build a web front end for it.

Oh, there's never been any problem with locking in the <thinks> 10
years they've been using it.

--
Krusty.

http://www.muddystuff.co.uk
http://www.muddystuff.us
Off-road classifieds

'02 MV Senna '96 Tiger '79 Fantic 250

 

emerged from their own little world to say

Sack the know-it-all ****.

 

Thanks. That's very helpful and confirms what I'd suspected; that the
solution whilst not optimal is workable.

Regarding the central database and distributed clients, I'll look into
the reasons for the web-front end approach. I'm fairly certain there was
*a* reason, just not sure if it's a valid one!

 

Please note I am a "no nothing" IT user not a "know something" IT
professional.

We get the comment you got about Access all the time at work. Us poor
simpletons who want to share information between teams are always told
Access will not be up to the simple job at allowing people to retrieve
or add data to a central database. It is also not compliant with "IT
Standards". Therefore we either spend a six digit number to get a
"proper" "compliant" database that takes eons to produce or else we
don't share information in a sensible manner. Guess which one we do?

I would strongly challenge your "IT background" person and see if a
simple but reasonably robust solution can be provided using something
everyone can cope with - that may or may not be Access in this context.

I doubt that helps but at least you are not alone in being given
unhelpful professional "solutions" to problems. I hate our IT
department.

 

wrote:

this

and this

don't necessarily tally. Regardless of which:

Well the IT team at my gaff refuse to support anything that uses Access,
because "it's shit". Oracle is their route to enlightenment, apparently.


--
Dnc

B1200 - +30bhp ~|~ ZZR1100 - faster when upright
V2300 - flat cap and rug ~|~ A6 2.5TDi V6 Quattro Sport

MIB#26 two#54(soiled) UKRMMA#26 BOTAFOT#153 X-FOT#003

 

Paul Corfield wrote

I love my IT department, wonderful I am.

 

Paul Corfield emerged from their own little world to say

Then you might find this new C4 sitcom entertaining. The series starts on
Friday but you can preview the 1st episode via the website.

You will particularly enjoy the scene with the shoe.

The one with glasses & hair is *so* much like a former coworker.

http://www.channel4.com/entertainment/tv/microsites/I/itcrowd/index.html

 

He is in part correct by suggesting Access isn't a solution driven to
stability for that many users, and also bearing into the equation the cost
of supporting it - which I suspect you do not bring to the equation and have
no concern for, but isn't something that goes away.

You can argue until you are blue in the face that you are right, and Access
is the only solution to allow you to work with your data but then you have
to bear into consequence the level of support and department generated costs
you are provisioned when it screws up, which with Access can be on a daily
basis - I know with the fullness of experience which I doubt some of the
non-IT people commenting on this post have, having worked for companies like
that for >3 years that use it on the scale that you are talking about.

I use Access but I don't use it FOR many users, I use it where I feel it
best fits which is definitely not for availability and stability.

 

" "

 

It's read only. Writing is done from a single, central, source. Given
that we only want people to read data is it an issue?

I want others to be able to access the information rather than relying
on multiple emails etc. to speed up a couple of processes in which my
dept. is on the critical path.

Well, the chap in question came up with the outline idea since he needed
the tool to do his day job. I delegated the development to another team
within my area since that's what they're there for (management of tools
which are generally written outside.) In this case I needed something
fast and didn't want to **** about with contractors/consultants and all
of the resulting faf that burns 3 months before anyone starts capturing
the requirements and then another 6 months *minimum* before we start
UAT.

My fear is he would prefer to write code than do what I need him to.

 

A simple truth.

That's because it doesn't make the grade.

Who do you work for?

This is true. You have to use the right tools to do the job.IT
amateurs trying to do a good job often get it wrong.

From an IT perspective, they always have to sort out the punters problems
when the punter didn't listen to good advice.

 

Oh, me too. Me too.

Probably *generally* the one I do; find non IT process solutions to
something which should require a simple IT solution.

He's too involved and emotional to be rational about this one.

Well, in this case it's an internal issue. I wish I could say it helps
to know that others have the same problems... Hmm, maybe this is
something that there's a best-selling management book waiting to be
written...

"Slaying the Dragon- Unlocking the power of information in your company
by destroying the IT department"

A bit like Up The Organisation's view on Personnel Departments.

 

What I mean is that if we distribute a stand alone database and then
issue updates to it there is no guarantee that the users will install
the updates on their PCs and will then be using an out of date set of
data which will give incorrect guidance.

 

Well, I've got to develop and support; it's a small project and not one
I'd get support from Corporate IT on.

I wasn't arguing, I'm trying to understand!

Thanks, useful.

 

One place I worked at had the same methodology. It was the same data but
each department used to print it out and re-enter it into their own system.

So you ended up with about 10 Excel spread sheets and god knows how many
local Access databases. The time spent doing all this work would cover one
competent IT chap doing a proper job. But I do agree that a lot of IT
people will use a sledge hammer to crack a walnut in a lot of cases.

 

Pah! where's the fun in that?

IT are all arseholes, HR are all psychopaths[1], Desktop Support are all
know-nothing fuckwits[2], finance are an obstruction to investment, R&D
live in an ivory tower etc. etc.


[1] Cough.
[2] Actually IME this one is sometimes quite true.

 

Well said. I guess you have the experience.

 

As Champ says, your current requirements seem to put your application just
inside the Departmental realm.

I'd just add that however no matter how temporary or tactical one might think
a solution is, and no matter how fixed one might think the scope of the
system will be, these things have a nasty habit of expanding rapidly and
turning into full-blown (CRM/billing/provisioning/network inventory/fault
management/delete as appropriate) systems. In which case, if you're still on
Access when this happens, you'll be in deep trouble.

Porting to SQL Server would be easy. If you need to keep this under the
radar of your procurement processes, MySQL would also work well.

In any case, developing your web front end is going to be the largest task in
the project - moving a single table from one DB environment to another really
shouldn't take more than an afternoon.

 

You'll more than likely get away with it, would be my take.

I'd suggest you ignore the technology for a few minutes. Consider
whether the users are in a position where they'll be able to demand more
functionality once they've got the data you're initially planning to
provide. If the answer is yes (and it usually is) then you might be
better making things scalable from day one.