Posts
832
Comments
691
Trackbacks
1
December 2007 Blog Posts
The Joys of Bad Customer Service

For one of our clients, we handle very basic web site maintenance tasks for them.  It's an already existing site (written around 2003 by someone else), so it usually involves very minor text changes and other related matters.

About 3 or 4 months ago, the hosting provider decided to move the web site to a new server.  They never informed the client that they were doing it (since I have in the past done hosting provider type work, I'm guessing it was a server decommission matter), they just did it.  Which would have been fine if nothing was affected.

Some of the admin tools started breaking and we were asked to investigate (which is how we found out about the server move).  Turns out that there was some custom configuration on the site, which they failed to move over along with the site itself.  Great.

Then, it was discovered that another, more significant part of the site was broken, and was actually leading to revenue loss as a result.  After a lot of back and forth, it turned out that on the new server, they hadn't properly installed the JDK.  One would think that would be an important thing to do.

This past week (over the holidays, of course, making debugging and troubleshooting that much easier), another piece of functionality stopped working.  There was no useful error message logged anywhere, just a generic "There has been an error, try again" type thing.  Great.  Consulting with the hosting provider, they decided that the syntax of a certain area of code was incorrect, and needed to be updated.

Okay, let's get this straight.  Site written in 2003.  Functionality unaffected since then.  Until server move.  Functionality breaks.  Hosting provider solution: rewrite code.

Still awaiting resolution of the issue, but it's amazing how much 'red tape' it takes to get even the most basic matters resolved. 

Happy Holidays.

posted @ Friday, December 28, 2007 1:08 AM | Feedback (0)
LINQ to SQL DataContext Show Stopper?

I have to be doing something wrong here.

If I have an Address and an AddressType, I find that the AddressType gets re-inserted when I create an Address, set the type, and save:

MyDataContext ctx = new MyDataContext();
Address a = new Address();
a.AddressType = AddressType.Get("Billing");
a.City = Chicago;
ctx.Addresses.InsertOnSubmit(a);
ctx.SubmitChanges();

The 'Get' uses a different context (of course).  In certain more complicated situations (which is where I started at before I spiked this simple example), the SubmitChanges call will fail because it doesn't like that a different context was used to get the AddressType.  You can make the get not track changes, but then you get the same issue.

This can't possibly be correct. This makes LINQ to SQL almost completely useless for anything.

I must be doing something wrong, it can't be this bad that you can't create a new Address, set its AddressType, and have your lookup table inserted into.

 

Update:

The following gets around the immediate issue:

LinqDataContext ctx = new LinqDataContext();
Address a = new Address();
a.AddressType = AddressType.Get("Billing");
ctx.AddressTypes.Attach(a.AddressType, false);
ctx.Addresses.InsertOnSubmit(a);
a.Address1 = "3505 North Claremont, #1";
ctx.SubmitChanges();

Now, this still strikes me as sub-optimal.  As you can imagine, it seems as if for a more developed Address object, you would have to attach (and you must use 'false') all dependent objects and so in a more complicated scenario, where the Address object itself is just a part of a checkout process, you end up having to do way too many attaches.  I'm going to see if this is the case.  It does work for this limited case, so I'll go with it for now.

 

Another Update:

I go into a more comprehensive way of using Linq to SQL and ASP.Net here.

posted @ Saturday, December 08, 2007 9:09 PM | Feedback (2)