?

Log in

No account? Create an account

Previous Entry | Next Entry

    accountant: The database is broken.
    self: Is not.
    accountant: No one can get into it.
    self: We had to shut down the server last night. It's fixed now.
    accountant: No it isn't.
    self: You may have to reboot to restore the connection.
    accountant: I have rebooted.
    self: Not since I told you to.
    accountant: Look. It's not my computer, and it's not the network. You're the database administrator. Go fix it.
So, I check the database from my system. It connects to all the linked tables on that server, no problem. This rules out the database itself, and the network.

Only thing I can figure is they must have told Windows to stop trying to connect to that mapped drive. It's a common mistake - Windows really shouldn't give you the option every time it fails to reach a network resource. I can fix it in eleven mouse clicks, but no amount of effort will ever convince the users not to make the same mistake next time it comes up, or to accept that the problems they cause are in no way my fault.

I head upstairs, sit down at their computer, and check for mapped drives. Still there. Well, that's something, I guess. Already, the situation could have been worse. I test the connections, and they're all fine. So, now we don't need to reboot either. There's nothing wrong with the database, the network, or this users computer. So, what's left?

Is it possible they got into the linked table manager and screwed everything up there trying to fix it? Doubtful. I can't think of any reason that utility would be installed here. But if that's what happened, I can replace their front-end interface in three mouse clicks, thereby erasing all the damage. Another thirty seconds would remove their capacity to do it again.

Just for fun, I launch the database to see what they've done to themselves before I set it right.

...and everything works.
    Oops! Sorry. False alarm.
    The implied accusations and the dragging you upstairs? Completely unwarranted.
    Turns out you knew what you were talking about after all. And, hey! I didn't. How 'bout that?


    Well, okay. That part went unsaid. But I'm sure they were thinking it.
*sigh*

Back in my freelance days, this was the one kind of job I wouldn't feel guilty billing for.

Comments

( 2 comments — Leave a comment )
robont
Nov. 14th, 2002 11:02 am (UTC)
what software are they using?
self
Nov. 14th, 2002 05:20 pm (UTC)
nothing too complex, unless we make it that way
They've got a few programs, but we're just talking about MS Access 2000 here.

Everybody's got an .MDB file on their desktop, which contains lots of forms, queries and reports but no actual data. Why? Because everybody's data needs to reflect the changes everyone else is making. So their .MDB files all reference tables in a central location (we'll call it \\officeserver\public\database\backend.mdb)

When I first got here, that pathname was explicitly defined in each user's .MDB file. Or rather, a different pathname was, left over from the old network. The company used to be split up across three buildings - we're all lumped together now, and I guess they revamped everything for it. Anyway, I had to re-link all the tables, and I wanted a little more flexibility, so I mapped drive O:\ (arbitrarily chosen because it wasn't likely to interfere with anyone's current drive mappings) to \\officeserver\public\database and told Access to find all those tables in O:\backend.mdb

In retrospect, that was a strange decision, and probably responsible for some of the confusion I described this morning. But if the users cut off one mapped drive, they'd probably drop the rest as well, and I'd already be up there fixing it for MAS90 and Quickbooks, so what's one more? Plus, being able to route one system's drive O:\ to a previous month's backup and run updated processes on that information has saved my life a few times.

And yes, you read that right. The database was designed (by someone else) with sort of a "snapshot" mentality. It represents our current state only - updates are made retroactively, as in "clients who sign up for a new service have always paid for this service, even before we thought to offer it." Our paper records are accurate, but the database itself is a rough approximation.

Oh, and it doesn't know the difference between one year and the next. If you don't manually clear out a month's transactions before you start entering current info, there's a very good chance someone will be billed or paid based on last year's info.

I've brought this all up with management, and they told me not to worry about it. So, without authorization to start it over from scratch (it'd take too long to enter past months' records by hand - anything I could cut-and-paste digitally is tainted), my job has been reduced to just helping folks deal with a bad situation.

But, yeah.. I have been charged with the task of speeding up the database, and the reason it's so slow is that we're doing everything internally through Access. ("Linked Tables" are just not efficient - they copy absolutely everything over the network into a temporary recordset, query that, and repeat as necessary. It's ironically much faster for Access to treat itself as a third-party datasource than it is to just function as designed) So, I probably will end up rebuilding quite a lot of this. Still, I don't see how I can transition into an accurate setup without replacing or abandoning the past, so that part will probably stick around long after I'm gone.

...and now I'm rambling. Did that answer your question?
( 2 comments — Leave a comment )

Profile

self portrait (escher)
self
some guy

Latest Month

October 2014
S M T W T F S
   1234
567891011
12131415161718
19202122232425
262728293031 

Page Summary

Powered by LiveJournal.com
Designed by Tiffany Chow