Google Search » Database Underground | Sean McCown » July 2007

July 30, 2007 | Comments: (0)

Visual Studio... Get With It!!

TAGS: Microsoft

One of the things that really frustrates me with VS 2005 is working with some of the server controls that don't work the way you think they should. Take the menu control for example. It would really be nice if it did more with direct data sets. Instead, you have to present it XML data, but only from like an actual XML file or the like. You can't just attach it to a SQL SP that spits out For XML. And even if you have a flat menu structure, you can't just tie it to a simple resultset and have a nice dynamic menu. Of course, these can be done at all, but not without some pretty thick coding. And the point of the whole thing isn't to code that much, but to have these controls do the work for you.

Another good example is binding data to a calendar control. VS doesn't do it from the calendar properties so again you find yourself up to your elbows to code the solution.

More often than not, I find myself not using these 'easy' built-in solutions provided by VS because in practice, few of them are that easy. Take the login control. You can have it be SQL driven, or windows driven. That's great, but what if I want a windows login site that's available from the outside world. It would have to provide you a method for logging in with your windows credentials when none are present. Now, I know this can be done because OWA does it just fine. But it's not easy, and it's not part of the properties setup by the control. And there's no easy way to use complex custom mappings from your windows creds to your application security. Let's say that I want to use windows auth for my ASPX pages. And inside my DB I have certain users or groups that have rights to individual pages or even rows of data that's determined by some logic inside either the front end, or the backend. There's no real easy way to map your windows acct to that security model. You can do it with the SQL auth because you can point it at the DB and tell it where to get the security, but with Windows you're left holding the bag with a much more complicated solution.

Let's see... oh yeah, I was talking about not using those solutions. Yeah, another reason I tend to not use things like the menu control, etc is because of the way they're implemented. You have to put them inside a form tag and once you get them inside a master page and put 3-4 other form controls on there, it can be hard to manage them and get them to work correctly. A lot of times it comes down to using one control or the other and it's just a pain. And again, even if you could use them all on one page (which I'm sure you can), it's so much trouble you're better off just using something else and saving yourself the hassle.

What got me on this topic were a couple vids I saw from TechED on LINQ. Frankly, I didn't really get the whole LINQ hype until I saw that one vid online. It's given by Luca Bolognese, who's about as Italian as you can get. He's always talking about Ferrari and ravioli, which is great if you ask me. Anyway though, it's an excellent intro to LINQ and he actually managed to get me excited about VS'08 which is something that I haven't managed to do yet. So I think I'm actually going to go download it this week and try to do some LINQ stuff.

One thing that I'm wondering about though, is whether they're actually addressing any of these other concerns. I'm not the only one who's noticed these either. And these are just the tip of the meatball. I do love .NET for how easy it makes some things, but you've really gotta do more these days. It would be nice if they would start crossing the finish line on some of these things and actually making some of these things easier to use. To this day, I still haven't used the Login control because every time I go to setup my provider in the site properties, I get an error. I'm sure I could troubleshoot it and get it working, but so far it's been easier to use a table adapter and just get on with my life.

Not to mix topics here, but the same thing goes for SQL Server and SSMS. Yukon was basically v.1 for a lot of these tools so I cut them a lot of slack. If we still see a lot of the same issues in the Katmai toolset I'm going to be a lot less forgiving. Especially if they're problems I know people have been telling them about for quite some time. I realize they can't put every feature everyone comes up with in the product, but there had really better be some significant improvement in the way these tools work or there are going to be a lot of SQL guys hitting the roof... myself included.

Anyway, I'm just waiting to see what they come up with.

Posted by Sean McCown on July 30, 2007 11:55 AM

July 27, 2007 | Comments: (0)

The New Guy

TAGS: General Database

It's always interesting going into a new gig. You've got the local politics to deal with as well as new systems to learn. There's really too much to pick up than I could ever cover in a blog, but you've all started new gigs, so you know what I'm talking about.

The other side of that coin though is what it's like to have to deal with the new guy coming in. You definitely get some guys who push the boundaries of what you're used to.

A really good example is this one guy we had at my last gig. He was there about a week, and we were standing around talking about how our Windows guy was going out for his anniversary that night. He was taking his wife to this one place to eat (I don't remember where right now). Oddly enough, that guy showed up at the restaurant while they were eating. He sat at a table near them and kept trying to make conversation. Now, I never did discover his motivation, or what he even hoped to gain, but from there on out he became this stalker and nobody really wanted that much to do with him. Then he started up this campaign of hiding behind cubes to hear what people were saying about him. It was all perfectly creepy. This was definitely a case where he had no idea how to become part of the group, and nobody in the group had any idea how to talk to him either. It was just a bad situation all around.

Currently, my situation is different from any I've ever had. I've been at my current gig for a year now and while I replaced the former DBA, he's still around. I've never been there before. Usually, the old DBA has moved on to different pastures.
One of the hardest parts of my job has been taking the role of DBA from him. He was the only DBA for a long time, and now he still sits right beside me, and it's taken a long time, but people are finally starting to see me as the DBA instead of that new guy who doesn't know nearly as much as the original. But yeah, even when they started coming to me with questions, they'd always go to him right after. I guess they just wanted to make sure the answers matched.

And I don't blame them in the least. It's a new situation for them too. They've still got the guy here that they're used to dealing with, only now they're being told this new guy is the man. People mostly resist change and I'm sure most of them didn't see any reason to switch DBAs.
So, things are starting to workout now, but it was really touch and go there for a while.
Part of the point here is that it isn't just tough on the new guy. It's also tough on the old guys. The new guy has new ways of doing things etc. and they're not sure how to deal with that. He may even directly disagree with what they've been told by other DBAs.

The big question of course, is who's responsibility is it to make sure things go smoothly? I've been told many times that it's MY duty to make sure that I fit into the bunch and it's not their job to make me feel welcome. Personally, I think that's a load of crap. You've got to realize that this guy is coming in here new and he's automatically out-numbered 100 to 1. He's not in on all the politics, or any of the funny stories you guys tell at meetings or anything. How much of an effort can the new guy really make? I mean, you don't invite someone over to your house for dinner and then treat them like crap until they prove they can fold into the workings of your house do you? I certainly hope not.

Anyway, I've got some more stuff to say on this general topic, but I'm out of time right now. Perhaps I'll pick this up again soon.
But for now, let's set a couple ground rules. When you start a new job, try not to stalk your co-workers, and when someone starts at your office, don't make them always have to come to you. Remember how completely they're out-numbered and try to bring them into the fold yourself.

Posted by Sean McCown on July 27, 2007 07:51 AM

July 26, 2007 | Comments: (0)

Personal vs Commercial Software

TAGS: General Database

As you can imagine I get asked by all types of companies and individuals to look at software. In fact, I probably get more requests to look at software than a lot of people even get email. And there's one thing that's becoming abundantly clear to me. People don't know the difference between personal and commercial software.

I used to think that there are so many poor apps out in the wild just because nobody knows how to code, but I'm starting to rethink that. Sure, there's a lot of that going on, but from what I've seen lately, there are a lot of developers out there trying to sell these apps they've written for themselves and assuming that they'll work the same for everyone out there, or that everyone has the same requirements. I'm telling you though, there's a huge difference between personal and commercial software.

I've got a coupld dozen apps I've written over the years to help me do my job at one company or another, and none of them are really ready for commercial use. And I would never dream of putting them out on the market because they're just too specialized. And most of the time, they're just simple little things I've written to save me some mouse clicks. I've written everything from indexing utilities, to things to help me manage DTS/SSIS packages. And most of it isn't hard enough to be considered commercial software either. And that's another peeve of mine. These guys who want $10K for something I could write in a couple days, and probably better. Or something that just puts a slightly different face on something that the native tools already do.

So seriously... for those of you out there who are considering selling an app that you've written, ask yourself these questions:

1. Is it something the rest of us can use?
2. Is it complicated enough that the bulk of the IT world can't easily do themselves?
3. Does it solve a wide-spread problem, or are you contriving a problem to sell software?
4. What will you have to do to make it a real commercial package?

I guess what I'm really trying to say is just think about it before you push another useless app out into the marketplace. I never want to keep anybody from taking their shot. I mean, if you've got an app to sell and a dream to make it big, then by all means, make it so. I would seriously advise you though to ask a few people first and get their honest opinions about it before you go bothering the rest of us. And by all means, price it appropriatly. I'm getting so tired of everything having to cost several thousand dollars per server for the simplest things.

Posted by Sean McCown on July 26, 2007 11:05 AM