Network Solutions, Nameservers and DNS work...

Look -- I've been in this web business for a long time. I first started web design, while doing other programming, back in 1995, 1996? I know the web. I'm pretty handy with the concepts of routing, DNS, etc. I'm no network guru, but after looking up the color sequences, I can build an RJ-45 cable. I even have my own tools. I've owned a website design business, pretty successful, too. We had staff and everything before we sold it off. We made Dallas Business Journal's Top 20 Web Design and Hosting companies three years in a row!

All this having been said, Network Solutions really angered me today. I quit using them for personal (or side business) stuff several years ago. GoDaddy rocks, in my opinion, whereas Network Solutions charges an arm and a leg for less services, less quality.

Now, even though *I* don't use them anymore, the company I work for does have several domain names registered with NetSol. That's fine...I'm not sweating it. But this week I needed to setup a new dedicated server (which I did at CrystalTech because they also rock) but didn't want to go through the hassle of having our current hosting company do DNS work, when we'll just be leaving them. And I wanted the control over the DNS records that I'm qualified to have.

So I finally got access and I see that they offer DNS management, much like GoDaddy does, so I'm thinking "Okay...I can do this." So I do.

First problem: I couldn't setup new DNS entries under the NetSol system unless I went ahead and confirmed that the nameservers would be switched. Why can't I set it all up, then make the nameserver change when I'm ready. Makes more sense...but noooooo.

Second problem: This is the one that really lit me up. I've done this a million times. I get the DNS concepts. I understand DNS propagation takes time. For those of you who might be reading and don't understand, here's a brief explanation.

• Zog wants to go to the website for www.foobar.com
• Zog asks the Internets to take him there.
• Zog's ISP says "foobar.com?" Wuzzat?
• Zog's ISP goes to "the almighty root servers" and asks "Where do I find foobar.com?"
• The root servers say "Check with Network Solutions".
• Zog's ISP asks NetSol, "Where's foobar.com?"
• Netsol says, "I know the answer, you want the www? Go to IP 266.266.266.5" (Yeah, yeah).
• Zog's Firefox says "Okay...I know that www.foobar.com is 266.266.266.5" and goes there.

Pretty simple. Now here's where NetSol screwed up. When it made itself the active registrar for the domain, it SHOULD have been able to pick up the IP address records VERY quickly. After all, it's their system. It's not like with propagation where all the ISP's in the world try to keep a list of domain names and who knows all the mail, www, etc. individual records. Those only get updated once or twice a day or more, I don't know.

The point is that NetSol's "worldnic" nameservers should immediately know the answer to "where's the www IP?" Once you (or an ISP) starts looking there, it should know the answer. Propagation is about all the ISP's getting the right information. Propagation is NOT about their own nameservers not knowing how to answer the questions.

Using DNSStuff.com, another great site, tells me whats' going on. First, it says that I have "lame nameservers". Other than the obvious pun there, it means that the nameservers associated with my domain name do not answer authoritatively. What? Why don't they? Another test on the DNSStuff site tells me that the root servers say "Check NetSol nameserver A". Nameserver A says "No...check back with the root servers." The root servers say "Okay...check Nameserver B, then." Nameserver B says "Check back with the root servers." Being round-robin, the root servers tell us again, "look at Nameserver A". You can see where I'm going with this. DNSStuff.com says it stops automatically after 20 rounds of this crap.

I didn't expect to bring down the site, email, etc. today. But I did. And it's not my fault. I did everything right, but Network Solutions decided to screw it up. And then their technical support tries to tell me this is normal. Lies. Period. I've done this same thing with GoDaddy enough to know that once you change the nameservers, it should say SOMETHING. Maybe not what you set in the last five minutes, but something.

How long will the site be down? I don't know. The nice tech support man said that it could be 2 to 3 hours before it has the right information. And that I should expect this. Made me angry, but I was polite. Now I have a batch file running an ipconfig /flushdns and ping www.foobar.com loop running. It's been running the whole time I've been writing this, and for an hour and a half before. Let's call it about one hour and 45 minutes. And it's still not working.

As soon as I get this straightened out, I'm moving the domain name to GoDaddy, where domain names belong.

- Will Belden
September 14, 2007

Illudium PU-36 Code Generator and Matching table and column names...

First, let me say that I love the Illudium PU-36 Code Generator. It has made my life a lot simpler, even when I find myself editing the xslt files to get code more like I want. But I truly cannot imagine life without it since Rob Gonda introduced me to it.

I will readily admit that I may not have the latest version. Once you start editing those xslt files, you kinda want to stick with it. But I ran into this issue today, and it took me a bit to figure it out. Here's the error:


Bean creation exception in com.model.vendorTypeA.vendorTypeAService
Cannot declare local variable vendorTypeA twice.:Local variables cannot
have the same names as parameters or other local variables.:
Line: -1



Obviously a line number of -1 isn't helping. It did tell me, though, that the object can't be created. This error, technically, is thrown by Coldspring, but has nothing to do with it.

The issue here is that I have a table called "vendorTypeA". It has a field called "vendorTypeA". This is bad. Here's the code portion, and it seems obvious, once you've been through this.

<cffunction name="createVendorTypeA" access="public" output="false" returntype="com.model.vendorTypeA.vendorTypeA">
<cfargument name="vendorTypeID_A" type="numeric" required="true" />
<cfargument name="vendorTypeA" type="string" required="false" />
<cfargument name="isActive" type="boolean" required="false" />

<cfset var vendorTypeA = createObject("component","com.model.vendorTypeA.vendorTypeA").init(argumentCollection=arguments) />
<cfreturn vendorTypeA />
</cffunction>

Note the two portions in bold, red. I have an argument of "vendorTypeA" and I'm trying to create a local variable of the same name. One is the field, the other is the object, which uses the table name as the object name. The easy solution here is to simply add "_obj" to the last two lines, as in:

<cfset var vendorTypeA_obj= createObject("component","com.model.vendorTypeA.vendorTypeA").init(argumentCollection=arguments) />
<cfreturn vendorTypeA_obj />

Problem solved. Now the object can be created, either "manually" or through Coldspring.

- Will Belden
September 10, 2007

SQL Server 2005, Views, Optimizing and UNION

I'm not typically a SQL View fan. I know many who are, and their arguments are all completely valid. In fact, I'm not much of a trigger or stored procedure fan, even though I clearly understand the benefits. It's just a "I like to have my code in one place" kind of thing. Crazy, but there it is.

Well, I needed a view. It was a three table UNION'ed join and....I just needed it simpler than putting all that nasty SQL in my ColdFusion objects. However, my modeling tool, PowerDesigner (PD), isn't always great with views that have computed columns. This particular view was performing too slowly, so I set about to add some indexes to it. Because of the PD problem, the indexes couldn't be built through the modeler. So I'd have to write the index code manually. As I began looking for the code samples, I found this page:
Improving Performance with SQL Server 2005 Indexed Views

One of the things I found was that if you do a UNION'ed view, and you use the same table names again, you should use different table identifiers. For example:

BAD:
SELECT * FROM Table T WHERE T.type="A"
UNION
SELECT * FROM Table T WHERE T.type="B"

GOOD:
SELECT * FROM Table Ta WHERE Ta.type="A"
UNION
SELECT * FROM Table Tb WHERE Tb.type="B"

When I changed my view's code to have this style, the speed on it more than doubled. And I hadn't even done the indexes that I was planning. I will, though...you just watch!

- Will Belden
September 4, 2007