After this I was ready to not be a consultant any more. Took a job with FlexJet in Dallas, being one of 3 DBAs, managing their database servers that ran their fleet management program. FlexJet at the time had about 100 business jets that would fly wherever their customers/owners needed them, being that they were time shares we had a lot more owners than planes. Due to this the scheduling of aircraft was extremely complex even compared to an airline, at least they know in advance what the schedule should be, we generally knew about 4 hours ahead of time where we needed a plane. Getting the right size airplane, to the right airport, could be a challenge. True 24 hour operations with world wide coverage (although most of it in the US, or at least US based owners).
The SQL code at FlexJet was full of code that was deprecated. To make sure we could upgrade to newer versions of SQL I went through every line of SQL code in the company to make sure it had no deprecated features, this included rewriting stored procedures, as well as rewriting dynamic queries in C++. Joy! The fun thing with this job was to use some of my skills learned in flight training and operations classes, being able to speak the language on both sides has some benefits. When I for personal reasons decided to move on (I considered moving back to Norway), they asked me to come work in their Copenhagen office and they would pay for my commute every week. Was very tempting.
Instead, I decided it was time to get my feet wet with replication. Something I had never done before. On the interview, as soon as the pleasantries where over, I opened by stating "I know nothing about replication, have never done it before, but so far have not run into anything in SQL I could not figure out. If that is not acceptable, let us not waste any time and call this interview over." I was there from the beginning of the project until 3 months after going live and handing it over to a permanent DBA to handle.
Replication was a challenge for sure. This was for a book seller, at the time they had about 75 stores. We set up replication to send inventory records out to each store as books where loaded on the trucks, then they where made active when they got scanned at the receiving end. We used about every different kind of replication possible, even to the extent that we could query sales live on the main server at head quarters, yet they could operate the stores even if communication was down. For early 2000s this was quite a big deal, last time I checked in with the DBA there 2 years ago the system was still in use, but quite expanded both by number of stores and scope of their capabilities. If their project has gone right, the new system should be out by now. Except for me, I believe all the programmers involved in the first version is still there. Great testament to the work culture at this company, one of the very few places I was on contract that I was sad to leave.
2002 came with the troubles after 9/11 and I was laid off for a few months, spent some time studying up on holes in my SQL skills while looking for a job. Being unemployed sucks. Finally landed a job with ABC Radio Networks (strangely enough taking over the job one of the DBAs from a previous job had held), responsible for databases running the radio operation. Had a great team of programmers and network engineers, some of which are friends to this day.
Had some interesting challenges at ABC. How to deal with 53 week years? WHHHAAT? Yeah it happens, and the way they wanted the report was 53rd week compared to the 1st week of the same year. Quarterly reports? Don't even ask. I have to admit I did a design flaw here by calculating it, should just have had a look up table that defined the reporting period. OR convinced them to use normal reporting where you would just compare week by week, and in the 53rd week the comparison year by year would be to the same week as the previous week. Live and learn. The function that would calculate this was one of the nastiest piece of code I have ever written.
One of the systems I took over had a table with a 12 column primary key, foreign keyed into a table with 16 columns primary key. Surprisingly it was pretty fast. Was a good challenge to write an archiving routine for this table, since when I got there we had 100s of millions of records in the table, most of which where not needed. The arching job ran in batches for the better part of a month to move data off the primary file. Later on SQL came out with partitioned tables for this. Oh how life has gotten easier over the years.
Wrote a search application that could search their entire transcribed news archive. In the beginning the users wanted to be able to search the result of the search, since their current search application was super slow they thought this was needed. Luckily convinced them to let me try it my way and just run a search all over again every time they wanted to narrow down the result. The day I demo'ed it for a few users they demanded I get it in production immediately, the searches all took less than 2 seconds on the entire data set, vs. 10-15 minutes in their current application. SQL wins!
I was there when Citadel bought ABC Radio Networks from Disney, due to certain activities I decided to move on. Having forgot that I had turned on nationwide searches while unemployed, the first call I got was from a company in Des Moines, Iowa. When they offered me the job I was watching TV with my wife, I turned around and asked her if she would be ok with moving to Des Moines. Yupp. After over 11 years in Dallas, 2 weeks later I had moved from Dallas, TX to icy cold Iowa. Had snow on the 5th day I was there. This might not have been a good move. Traffic was, however, much better.
No comments:
Post a Comment