Re: What database shall I use???

From: Pete Cresswell <x_at_y.z>
Date: Wed, 13 Mar 2002 00:32:19 GMT
Message-ID: <akoq8ug4646hotghl8gek0vhtvece1d683@4ax.com>

RE/
>As I've never had that kind of client, I don't know how difficult
>such a negotiation would be. However, proper management of the
>network environment is required for an Access-only solution to ever
>be viable.

Those are, until recently, the only kinds of clients I've had: departments in beeeeeeg companies. (i.e. over, say 5,000 employees on the same site as I'm working at) . This limited experience obviously must skew my view of things.

Because of what grey heads in IS say and because of what's most often written, I keep *telling* people they should be running client-server for mission-critical apps, but they never do.

Maybe that's in my own best interest because if one of them said "yes" I'd have to climb a pretty steep learning curve because beyond playing around with MSDE and SQL Anywhere a little I'm a client-server virgin.

My newest client was *that* close to setting me up with a copy of SQL

server to work with..    200 employees are going to be logging their
hours into a JET DB.    How many will be doing it concurrently?   Only
The Shadow knows.....I told them about my reservations, but they but

they chinced out at the last minute and opted for JET I am going cover my butt by coding it for the most seamless conversion to SQL Server that I can come up with and just keep my fingers crossed.

My experience is that companies beyond a certain size for quite logical and defensible reasons, exercise a great deal more control over things like LAN security, which development tools are used, and how those tools are used.

In outfits that size, bringing me in is basically a department-level user going against IS's desires because they feel that they need an app up and running a long time before IS can deliver.

IS, then, regards developers like me as something akin to lice: something that, unfortunately, is there but which needs to be exterminated and/or prevented whenever possible.

Negotiations in that situation are often somewhat, shall we say, strained. After all, here's a department that's basically told IS to shove it and brought in an independent developer that is going to leave behind heaven-knows-what developed using coding and other standards that differ from IS' and which IS is probably eventually going to get stuck maintaining.

You'd think that the 'getting stuck maintaining' part would be leverage to deal with them: "You scratch my back and I'll scratch your back by trying to implement your standards." But it doesn't seem to work out that way. For one, their 'standards' are often something that some guy that they didn't trust to program came up with and aren't exactly revered by the rest of IS.... and for another, their scheme of things (especially deployment) lends itself to VB builds and such, but not MS Access.

OTOH, I'm starting to get jobs with smallish companies now where I can talk to /work with the LAN manager and together we can do just about anything that needs to be done. It's entirey, totally, completely different.

Pete Cresswell Received on Tue Mar 12 2002 - 18:32:19 CST