Andy Kopciuch's Blog
Tuesday, January 11, 2005
  Blizzards, SQL Scripts & Sunglasses
O.K. So I've finally dug myself from underneath the massive amount of snow dropped upon the west coast since last Friday. Victoria recieved about 1 foot of snow in a day or so. Further up the Island had over 1.5 feet, I heard. Much of Vancouver Island was without power for some time. It really didn't affect me all that much. I was sick on Friday and didn't venture out anyways. We still had power in Victoria. The roads were still kind of rough on Saturday. People from the island really don't know how to drive in winter. They also need to learn to not let your tires go completley bald. There is a reason they are built with treads in them. Tires should always have treads. It keeps your car out of the ditches.

I've been pluggin along lately. Nothing really fancy. Just standard, PHP make it work, scripting. The joys of this project come from working with MS-SQL Server. I know I've found several oddities that just make my brain hurt, and my rants fun filled. I'll share the newest one with you.

I have a server running on the laptop for development, and I want to export everything to the devel server so everyone else can use it. I thought I had done that during my last visit, but apparently there were some errors happening. After my short investigation I discovered the row insertions were failing becuase I had NULL values going into NOT NULL fields. That seems rather bizarre to me, and not something I normally miss in my DB design. So I open up Enterprise manager and check things out. It seems as though the data import did not carry over the default value constraints from table to table.

I went on a mission to try and find and easy way to export a table definition(s) from one DB to another DB on different machines. The export wizard did not seem to work. It's not very intuitive to do something like that in SQL Server. It's soooooooooo easy to go:

pg_dump -s -d <database> -t <table> > table.sql

Do you think there is a simple way to just get the table defs in MS-SQL? Tasks like this are exactly the reason why I really _dislike_ GUI for administration activities. Some people will say "But there are all these tools out there to do things for you, why not make use of them,. It's not that hard to learn them."

Why should I learn an awkward tool, that provides what I would say is fairly basic functionality, so that it can provide these simple features in a several step process. That simple one line of typing for a PostgreSQL system is translated into these steps for MS-SQL Server
  1. Open Enterprise Manager
  2. Dig into your DB tree to find your database (could be several steps)
  3. Right click on your DB, choose "All tasks", then "Generate SQL Scripts"
  4. You now have to click on the "Show All" button
  5. Select the object(s) you wish to script
  6. Click on the Formatting tab
  7. Select the "Include entended properities" checkbox
  8. Click on the "Options" tab
  9. Select the checkbox for "Script keys, constraints and defaults" etc.
  10. Then you get to browse for a place to put the file you want the script in
That's 10 ... count them _TEN_ , non-obvious, rather annoying, and possibly dangerous steps if you happen to do something wrong and run a broken SQL script. I realize it's possible for anyone to screw any task up, but this process to simply dump a table definition to a file is just asking for trouble. Not to mention the large amount of time I spent trying to figure this out. I am by no means claiming to be the "Greek god of DB administration", but I'm by no means a bug on the windshield of the RDBMS SUV. Keep in mind this hasn't even touched on loading this script into the other server. I couldn't even figure a way to do that in Enterprise manager. There is probably a way to do it, but I don't know, and couldn't give a microscopic care to find out.

I had to open another program "Query Analyzer" and load a script from a file into the analyzer and then run it. I gave up on this method of doing things when I started to get results like this:

Warning: The table '' has been created but its maximum row size (10271) exceeds
the maximum number of bytes per row (8060). INSERT or UPDATE of a row in this
table will fail if the resulting row length exceeds 8060 bytes.

Maximum number of bytes = 8060?!?!?! Per row?!?!?! I'm not sure where 8060 comes from? If it were an 8kb row max wouoldn't the value be 8192? Maybe they have some wierd system table information stored that takes up 132 bytes? Odd ... very odd. At this point I don't even care anymore.

I did discover that you can basically run through almost the same process in the Export Wizard. You have almost just as many steps as exporting to scripts, because you have to register sending and recieving servers, and authenticate. Then the servers communicate with the Microsoft OLE DB blah blah blah object something, spinning pictures, percentages ... O.K. All Done! I ended up doing the import through the wizard, but I _hate_ a procedure like that. Here's why:

I already know that a straight export into (valid) SQL scripts and importing produces some funky warnings. Not that the information said warnings provide is useful really. What has happened to these warnings from the import wizard though? Our GUI friends have been so wonderful to provide me with an awkward tool for me to spend a great deal of time to do a simple task, and to help me out their wizard doesn't even warn me about possible problems I _know_ are there, only becuase I wasted a great deal of time trying to figure out how to do the simple task a completely different way with another set of the awkward tools they have so graciously provided me with.

Just provide me with a peice of software that does exactly what it's supposed to do. Give me a way to control what it's supposed to do just by telling it in the simplest manner possible. Don't make me learn several other pieces of software just to interact with the major software that does all of the work for me anyways. What a bad set up! I'd prefer to actually expand my knowledge and learn the proper way for some technology to work (like knowing how the SQL definitions should work ... for any RDBMS ... not just specifically to one project). But using a toolset that is hard to work with, doesn't even do a very good job of things, and involves me trusting that it's doing what it's actually supposed to do is a bit much to ask of me. Microsoft seems to ask that of me alot. Trust is the issue in the world of software these days, and I don't have much trust in MS products.

I do however trust my sparkly new sunglasses to keep the UV rays from my eyes. I was so excited today when I actually got to wear them on the drive out to Sooke. The sun was shining today ... what a nice feeling.
 
Tuesday, January 04, 2005
  Luggage, Standards & Stat Holidays
So I'm back out on the coast again. It was a hectic adventure this time. Christmas was quiet as I was sick for most of the Christmas and New Years experience this year. I stayed at home mostly and watched movies, and coded. I did get a great deal of the DMS features completed. I still need to work out ACLs, and re-parenting. AJ has been using it already and has been picking my brain on features, and how to organize things. It's a fairly robust and useful back end for document storage I must say. Cudos to Aaron for the initial work, and thanks for his brainstorming with me on new features. :-D

So I did the typical Andy thing of staying up all night the last night in town because I put off cleaning and laundry way too long. But I managed to get everything I needed packed. Went to a last band practice which went quite well, and then I was off to get AJ and then to the airport. It should have been a simple trip. That turned out to not be the case. The flight was late leaving to begin with, but I wasn't worried at all becuase I had a 1.5 hour layover in Vancouver before I hopped to Victoria. Smoking rooms in airports are _GROSS_. I mean I smoke, but I was even getting sick in there!

So I arrived in Victoria on time. Karen's beau Johnny was picking me up (THANKS MAN!). We were kind of pressed for time as he had band practice @ 7:30, and I got in at 6:30. I had to wait for my checked bag. The bags came out, and then the conveyor belt stopped. No more bags were loaded. I was without luggage! I had to wait in line and give my information. "I don't know the address where I'm staying ... If it was my house I would have needed to pack a HUGE hockey bag full of stuff! I don't understand this. Their only job is to take my bag off one plane, and put it on another plane. The tag on the bag even tells them which plane to put it on ... and they managed to fuck that up. UNBELIEVEABLE!" So without my stuff (Good thing I had my toilet kit in my carry-on). I went with Johnny, we picked up some drinks and I went to his band practice with him.

Upsatairs in the attic of some guys place. Amps, drumset and not a whole lot of room. It was going to be cool. I met "Hammer", "Greyskull", I already met "Bootface" once. We call Johnny "Pukeface" so everyone has a nick name. I jammed on the drums for a bit. Johnny normally plays bass, but is a drummer at heart. Since their regular drummer was AWOL, they were just jammming and Johnny sat in on drums. The band is called "Nibbler" Really awesome group. I highly recommend seeing them if you get the chance when in Vancouver. Hard Core punk. In my humble opinion they sound like a cross between The Dead Kennedys, Megadeth, and The MightyMighty Bosstones. That makes for some interesting but still very cool jamming.

So I stayed the night at the house again. I finally got my phone calls from Air Canada. I decided on Monday morning that enough was enough and I would just go get it myself instead of letting they try to deliver. They first issue was that Karen's car was blocking us in. No problem .... she left her key for us. Too bad I don't drive standard! Backing out of that long driveway is a treat in my own car, but trying it in not my car, and not being able to drive a standard ... well it was an adventure. I finally got it parked, then I couldn't get the key out! Oh shit. So after 10 mins and a phone call to Rich, I finally found the key release underneath the steering wheel.

Get my luggage at the airport, grab a bite to eat, and off to Sooke to meet Power Soft, let them know I'm around, and will be in tomorrow. I get out to the office, and it's all locked up. Nobody was home. I was checking my phone to see what day it was (Sun or Mon). Yup, it's Monday. Thinking in my head ... where is everybody? I phoned Chris but received no answer, I did get a hold of Brenda and right before they answered I realized that they would have been closed in lieu of New Years Day. Since Jan. 1 was a Saturday, businesses close on Monday for the Stat Holiday. Since I work for myself and I never think about Stat Holidays, it never dawned on me. I alse realized about this time that I forgot to email everyone and let them know I'd be back. Oops.

Well I'm arrived, have my computer all set up and geared to go. I did fix a couple of path problems, and got the dev server working with my PHP scripts. It was just some incorrect paths going on. display_errors is turned off, so I just turned it on in ini_set(); Saw my problems immediately. Good to go. I'm going to finish some small tasks tomorrow, and then we should be ready to go on the next phase of tasks. I'm sure I'll rediscover my dislike for MS-Enterprise Manager. :-(
 
The Jolly Smoking Computer Programmer

ARCHIVES
October 2004 / November 2004 / December 2004 / January 2005 / February 2005 / March 2005 / April 2005 / May 2005 / June 2005 / July 2005 / August 2005 / September 2005 / October 2005 / November 2005 / December 2005 / January 2006 / February 2006 / March 2006 / April 2006 / May 2006 / June 2006 / July 2006 / August 2006 / September 2006 / October 2006 / November 2006 / December 2006 / January 2007 / February 2007 / March 2007 / April 2007 / May 2007 / June 2007 / July 2007 / August 2007 / September 2007 / October 2007 / November 2007 / December 2007 / January 2008 / February 2008 / March 2008 / May 2008 / August 2008 / October 2008 / December 2008 / January 2009 / February 2009 / March 2009 / May 2009 / August 2009 /


Powered by Blogger