There have been some reoccouring questions:
How do I move a web service
How do I keep my code updated with respect to changes in my database structure.
There stock answers are:
You should never need to move a web service.
You should design your database up-front so it should not need to change.
These are grossly simplified. I have encountered a case where a website had to move due to legal questions about the name – the site had been located where it was for a year. Web services can and will suffer the same fate.
Database structures will change. We had to add an entire subsystem to the product that we are working on to support one line in the requirements. Change happens. The trick is to use tools that minimise that change. That can mean restricting the use of strongly typed datasets.
Guys please think about your snappy answers.
Developer Rants 
Hey Chris, can you tell us all who said that and in what episode? Perhaps a time stamp? Sounds like sarcasm to me.
Hi Carl,
Thanks for being the first non-spam person to comment.
That post was a cheap shot – I had not actually expected an answer.
I can’t remember which episode as I am currently in rapid catchup mode listening to around 5 shows per week (it was probably around 30-50). It is a rather large archive to search
The comment about web services was one of yours. If I recall correctly you were saying that a web service is like a public utility and that it should be always on. This would be true for the big players like Amazon or Payplus. I guess that it is a bad thing to be tightly coupled to something that you are tring to use to decouple systems. Welcome to Catch 22. In time I think web services will need some sort of system to indicate that they are going to change – something like a time limit on the contract (i.e. I promise to provide these services for x years by which time I will either renew or expire).
I think the comment about database structures was by your friend who just loves Jet/Access. It related to the construction of strongly typed datasets and the hassle it is to recreate them when the table structure changes. I prefer Kathleen Dollard’s solution to the one provided by Microsoft.
Anyway thanks for putting out such a great show (I am currently upto the late 80’s). I may not always agree with your ideas (I am a Delphi developer at heart) but do find the show informative and enjoyable.
Heh… didn’t know I had any friends who like Jet/Access, or were you talking about Bill Vaughn who HATES Jet. It really sounds like something sarchastic he would say. He always says the opposite of what he really means. He’s very dry.
About the web service thing, I think what I was trying to say was in response to people who don’t think they should hard-code URLs to web services in their applications because it could move. My answer was to use DNS if the server needs to move, and to keep the URL alive. In other words, change it at the server, not on the client. That’s something I say quite a lot.
If you told me what episodes you were listening to I might be able to comment further.
Thanks!
Carl
Carl,
I had tried to put {sarcasm} tags around my comment about Bill but the blog software stripped them đŸ˜‰
I agree about not hardcoding URL’s. I try hard not to hardcode anything that could change. The problem with using a DNS for this is that sometimes your Domain name can change. I know of one case where the name of the domain was challenged and it was easier, quicker and cheaper to move the domain than to get into a legal dispute.
Thanks for taking the time to answer these questions and for putting out such a great show.