Comment On Cut, Paste, Destroy

So looks like the WTF is on the DBA of the SQL Database? Give users authority to do something, and they will inevitably do it.

*ahem* The Real WTF(tm) is that they use Access.

There, now it doesn't have to be said! :)

ComputerForumUser:

Oh man you all beat me to the first post.

Oh No!! The world's going to end.

Seriously, though, of course they used Access. They needed access to the database records after all.

I'm surprised the application was running under Administrator.

Microsoft Access:

You are about to delete XXX record(s).

If you click Yes, you will not be able to undo this Delete operation.
Are you sure you want to delete these record(s)?

I meant to say WASN'T running under Administrator

overheard at the IT fast technology drive through.

Yes, I'll have a MCfries, MCBurger, and MCdba to go. Nothing extra on the MCDBA please. We dont need any proactive thinking....

Some DBAs are more aware of potential problems than others. Like the earlier post - if you give users the right to do something they WILL do it sooner or later. Perhaps they don't even have a DBA?? Using Access without setting common permissions tends to support that.

Saladin:

*ahem* The Real WTF(tm) is that they use Access.

There, now it doesn't have to be said! :)

They were using VB too. I'm having trouble deciding which is The Real WTF.

I've had exactly the same problems with Lotus Notes databases. Over the years I've concluded that you just never, ever give end users real delete permission in a database.

Instead, you have a "this record is deleted" flag that excludes the record from almost all processing, and let them set that. Then you create a view showing which records were flagged as deleted, when, and by which idio^H^H^H^Huser.

it's a fine line between empowering users, and locking things down so tight if they need anything remotely out of the ordinary they have to consult the overlord. I put forth that if people know how to use tools, let them do their jobs. If they are doing something they do not understand then the burden falls on education and policy.

It's an age old problem, do you enforce policy through access rights and do everything your self, or enforce policy through education and high expectation so the team can move forward?

I work in an environment where many users are trusted beyond what I should be comfortable with (and this comes from above me), and I have to cleanup messes from time to time.
In implementation this turns out being better then everyone being locked down so tight I have to do their work form them.

The real WTFs are that they didn't have a way to find out who had done it in advance, they didn't build one in time to catch it happening again, and that they thought they were done after they revoke these people's delete privileges.

They should have done the MS SQL Server equivalent of this:

create view customer_v as

select    ...

from      customer

where     not is_deleted;



create rule customer_delete as on delete to customer_v do instead $$

begin

    insert into customer_audit (who, when, which, what)

                        values (user, current_timestamp, old.id, 'delete');

    update    customer

    set       is_deleted = ture

    where     id = new.id;

end$$ language 'plpgsql';



grant select, insert, update, delete on customer_v to whomever;

revoke select, insert, update, delete on customer from whomever;

Seriously, who doesn't have audit records in this day and age?

Access ... the AOL of databases.

VB ... the AOL of programming languages

The real WTF is that so many users needed reports in a way they could use, and that the system didn't have that functionality

Man, "the real wtf..." posts get old fast.

Anyway, sounds like typical silliness by the dba, as others have indicated. However, the applications aren't blameless either.

I'd be curious to know if the fact that real records were being exposed in a way that users who were just trying to get reports could delete them was by design, or simply an oversight. I've seen stranger things than that considered "by design"

Louis Cypher:

VB ... the AOL of programming languages

Converting from VB to .NET is like putting lipstick and a wig on a pig.
== WTF

Microsoft Access:

You are about to delete 103 record(s).

If you click Yes, you will not be able to undo this Delete operation.
Are you sure you want to delete these record(s)?

Yes! Uhmm, did I do something wrong?

Really bad admin skills.
"What do you mean by 'create more than one database'?"
"Access levels? Nah we don't dig that here!"

Once upon a time we used to have same kind of problems with JD Edwards World on an AS400. The "Dream Writer" reporting tool left a lot to be desired. AS400 guys were clueless about anything that wasn't RPG and didn't want to know about it.

Most end users ended up exporting data to Access (outside of IT) and making financial decisions on data that IT couldn't verify. Serious SOX problem. JDE would have monthly sales figures that didn't match the Access stuff.

IT tried to convert the Access (userland data mart) to a real SQL Server instance (with OLAP) but executives thought it was too complicated to use xls pivot tables. Go figure.

So I imagine users looking to Access to solve their needs is pretty common. Not that it isn't something to cringe about!

Don't even get me started on Access. There is absolutely no way I can persuade my employer to stop using Access/VB for the project I'm working on right now. It is the worst compilation of hacks and DRY-principle breaking crap I've yet to set my eyes on.

I'd almost prefer taking the performance hit of reading a file to working with Access ever again. It is simply one big WTF in itself. Then again, we are doing this Access was never meant to do: manage data.

Back on topic, before I get ranting (too late):

Like has already been mentioned - fair enough that they want to use Access for the mortals on the frontend, but why Lord, did anyone give access for the Access module to alter or delete data? That's an even greater WTF than using VB/Access in the first place.

Louis Cypher:

Access ... the AOL of databases.

Yeah, easy to use, easy to train, easy to develop queries using the QBE grid, easy to deploy, cheap, etc.

Everyone wants to bash Access because it makes them seem superior. It's like bashing Sony because of the PS3 when they own a XBOX.

You see, Access is a tool. It is very good at the things it is supposed to do, and very bad at the things it wasn't designed for, much like SQL Server.

You are never going to design a reporting system that will not require the end user to develop their own reports. I sure don't want to pay a bunch of Crystal Report writers or SQL report writers to sit around and respond to report requests. I would rather train the users how to write their own report using Access, Business Objects, or Oracle Discoverer. Let the end users decide how to query their data.

However, reporting users should never have anything but read-only access.

Original CAPTCHA: gotcha.

My improved CAPTCHA: MSAccess

Access is a great reporting tool. Departments are always wanting new reports and tweaking existing ones. IT can't keep up. Like someone else said, Empower the users. Give them MSAccess and a little instruction and they do it themselves. Well, mostly...

Of course, the real data still has to be secure in a central database.

triso:

Microsoft Access:

You are about to delete 103 record(s).

If you click Yes, you will not be able to undo this Delete operation.
Are you sure you want to delete these record(s)?

Yes! Uhmm, did I do something wrong?

In such case, the best is to ut a dialog askig if you're sure you want to delete, mentioning that the operation cannot be undone and have three buttons (yes, no, file_not_found), written in japanese.

mathew:

Instead, you have a "this record is deleted" flag that excludes the record from almost all processing, and let them set that. Then you create a view showing which records were flagged as deleted, when, and by which idio^H^H^H^Huser.

I once worked on a system that had a flag like that: they called it the "logically deleted" bit. Interesting thing was, they also had a "physically deleted" bit!

Perhaps the system was overengineered...

Lol - this is the very reason we coined the term "luser" back in the days! :D

*vanishes into a cloud of comfortable superiority*

Louis Cypher:

Access ... the AOL of databases.

Louis Cypher:

VB ... the AOL of programming languages

:%s/AOL/United States/g

sad story, but so typical...
microsoftware is mostly used by incompetents, that's why most software for microsoft environments is as incompetent as their users and developers (which are users too).

microsoft-side, things have improved a lot in recent years. but the users are as incompetent as ever. even though i'd totally defy being constrained by an operating system (like vista does), it's good that the incompetents simply can't do as they please any more.
with a little luck, we even might see a decline of spamming and ddosing pwned workstations soon. fingers crossed.

Companies that use Access for big applications are like the web design client that balks when you state your price.

"You want how much just to build my simple online store?" the customer asks incredulously. "My 15-year old nephew can build it in half the time for a tenth of the cost!"

Then they come back crying six months later and you charge them a bit more because you have to fix the site as well as rebuild it.

What the hell does ture mean?

Tukaro:

"You want how much just to build my simple online store?" the customer asks incredulously. "My 15-year old nephew can build it in half the time for a tenth of the cost!"

G** d***, I hate that.

When you say to a client "That will be $X" and the client says "but my friend's brother can do it for $(X/5)"...

Then after his friend does a badly-done job, the client quickly comes back crying.

BitTwiddler:

I once worked on a system that had a flag like that: they called it the "logically deleted" bit. Interesting thing was, they also had a "physically deleted" bit!

Perhaps the system was overengineered...

I dunno, that makes sense to me. Probably means, "The space this record physically occupies is now up for grabs." A lot of database systems are only a hairsbreadth away from file systems in how they manage the low-level physical resources.

Textbook "how not to do a SQL implementation":
step 1. Allow end users to execute ad hoc queries.
step 2. Fail to set very restrictive permissions (ie users performing ad hoc queries are not allowed to insert update or delete *anything*).

>Access is a great reporting tool. Departments are always >wanting new reports and tweaking existing ones. IT can't >keep up.

Exactly. I want a report showing me how many of my Acme printers are about to come off warranty. So I could fill out an IT work request form, give it to my boss with a justification, have him sign off on it, send it to IT who assigns a work order number then schedules a one-hour meeting for a week from Tuesday to get the requirements and promises a 14-day turn-out for the preliminary product which of course isn't exactly what I want, so I have to wait another 14 days till I finally get my report, unless of course there's an IT crisis (which there always seems to be one). Or I could use Access and do the report myself and have it done in 15 minutes. <Additional snarky comments deleted by the author>.

Clearly, regardless (or perhaps because) of the user expertise and the reporting tools used, read-only views should be the norm.

S|ic3 X:

Textbook "how not to do a SQL implementation":
step 1. Allow end users to execute ad hoc queries.

The real WTF is that that's the exact reason for SQL.

You whippersnappers might not realize this, but before database products with SQL were invented, someone had to specifically tell the system which queries the users were going to give, and specifically optimize the system for those queries. And if you wanted to ask a question that wasn't one of those queries, well tough luck.

SQL, like many good tools, allows you to do brilliant things. The price for this is that it allows you to do stupid things as well.

slamb:

...
They should have done the MS SQL Server equivalent of this:

..

    update    customer

    set       is_deleted = ture

    where     id = new.id;

...

Seriously, who doesn't have audit records in this day and age?

This is turely good code

"Converting from VB to .NET is like putting lipstick and a wig on a pig. "

Care to explain why? What framework would YOU choose?

> Seriously, who doesn't have audit records in this day and age?

If you can seriously ask that question, you haven't gotten around much. Screw audit records, I know plenty of people --- individuals and companies --- who don't have *backups*.

G-Unit:

"Converting from VB to .NET is like putting lipstick and a wig on a pig. "

Care to explain why? What framework would YOU choose?

Don't hold your breath waiting for an answer. I doubt the guy has used VB.NET.

I also have to defend Access here. Sure, it's no industrial-strength RDMBS, but I've heard lots of misinformation about it. Someone I worked with worried it wouldn't handle over 10 MB of data. He obviously never used it heavily enough to make the claim.

Access isn't great, but it's still better than most people claim. It just seems fashionable to jump on the Access-bashing bandwagon.

G-Unit:

"Converting from VB to .NET is like putting lipstick and a wig on a pig. "

Care to explain why? What framework would YOU choose?

Mumps!

BitTwiddler:

mathew:

Instead, you have a "this record is deleted" flag that excludes the record from almost all processing...

I once worked on a system that had a flag like that: they called it the "logically deleted" bit. Interesting thing was, they also had a "physically deleted" bit!

Perhaps the system was overengineered...

This gives me a *good* idea. How about a "disavow" flag. Any attempt to select data marked as such will result in the message: "The database will neither confirm nor deny the existance of the data you are querying."

Lederhosen:

Converting from VB to .NET is like putting lipstick and a wig on a pig.

Hmm.. Your analogy seems to be a little broken.

I think you're trying to refer to .NET as a pig - a common reference. Except .. well .. you wouldn't have the pig to start with, so putting stuff on it isn't the same as the conversion you're trying to describe.

So what you meant to say is probably closer to "Converting from VB to .NET is like trading in your blonde (and relatively simple) model girlfriend for the same blonde (and relatively simple) model girlfriend 500 Big Macs and two months later."

Yeah. That's definitely more like what you meant.

WIldpeaks:

triso:

Microsoft Access:

You are about to delete 103 record(s).

If you click Yes, you will not be able to undo this Delete operation.
Are you sure you want to delete these record(s)?

Yes! Uhmm, did I do something wrong?

In such case, the best is to ut a dialog askig if you're sure you want to delete, mentioning that the operation cannot be undone and have three buttons (yes, no, file_not_found), written in japanese.

Technically, there should only be one button on that dialog. It should say 'No'.

DELETE from Customer where CustomerName like "^X";

Oh, there's the problem!

Zemyla:

S|ic3 X:

Textbook "how not to do a SQL implementation":
step 1. Allow end users to execute ad hoc queries.

The real WTF is that that's the exact reason for SQL.

You whippersnappers might not realize this, but before database products with SQL were invented, someone had to specifically tell the system which queries the users were going to give, and specifically optimize the system for those queries. And if you wanted to ask a question that wasn't one of those queries, well tough luck.

SQL, like many good tools, allows you to do brilliant things. The price for this is that it allows you to do stupid things as well.

Yes. We know. We tried that. It failed. The real price for allowing users to use a good tool is that they will do those stupid things. So nowadays, we prefer that they clear their reports through IT. Call it job security, as in, "I won't get fired for not allowing users to run SQL themselves".

Anyway, my users would not understand SQL anyway. They barely understand the (exceedingly simple) web applications.

I like how so many assume a dba was even involved.

Here's a handy tip for you guys copying and pasting records from the database to your Office document. Instead of using copy-and-paste, use cut-and-paste. That way it's a lot easier to keep track of which records you've already pasted.

You'll get a warning message each time you cut, but just click "OK." You're working on a query result, a local Access-formatted copy of the records (see? there's the file for it on your hard drive). It's not the real records from the database.

Go nuts! Have fun!

Your amateur tech supporter from Sales,
--Rank

I disagree with what people are saying about using Access for report building. At work we're currently working to allow people to build their own reports except we're doing it with SQL Server 2005 and Reporting Services. We are currently working on having customizable, saveable reports using these two technologies.

As for the Access bashing, I think Access HAD its place, but since its rate of being abused is practically 100% (it's so close to 100 that we have to just say it's 100), then I would never want to write anything using it.

I've had to deal with too many Big Balls of Mud that use Access to ever want to see it again. There's too many free SQL products out there to justify Access. Hell, give me SQLite before Access.

H3SO5:

Tukaro:

"You want how much just to build my simple online store?" the customer asks incredulously. "My 15-year old nephew can build it in half the time for a tenth of the cost!"

G** d***, I hate that.

When you say to a client "That will be $X" and the client says "but my friend's brother can do it for $(X/5)"...

Then after his friend does a badly-done job, the client quickly comes back crying.

Why, exactly, do you hate that?

If you're too much of a snob to charge your friend double the money to rescue his self-engineered disaster, I'd be happy to oblige. Pass him on to me, and I'll pay you the 10% finder's fee (on completion, of course).

I don't even mind the crying. It makes my job worthwhile...

Mickey:

G-Unit:

"Converting from VB to .NET is like putting lipstick and a wig on a pig. "

Care to explain why? What framework would YOU choose?

Mumps!

No, no, no.

Mumps is the obvious replacement for VB.

To replace .NET, what you really need is Rubella.

WIldpeaks:

In such case, the best is to ut a dialog askig if you're sure you want to delete, mentioning that the operation cannot be undone and have three buttons (yes, no, file_not_found), written in japanese.

Seeing today's TDWTF, I see I had a lucky guess :-)