SnTT: Who are YOU pointing at?

It’s been a long time since I have done one of these, but this is one of those items that will bite you in the butt if you’re not careful. It’s really one of those ‘app dev 101’ things. I’m blogging about it because it happened to one of my customers.

A customer had a database that was very slow when users were entering data in a form. I found out that this customer had moved the database to a new server, and that was when the problems began, so immediately I thought that we had some ‘locked in’ names somewhere. Upon closer inspection, I discovered that the form was refreshing on field changes. I then found a few of the problems… I had a doclink that went to a nonexistant database on the old server, and I also found a couple of actions that had the old server name ‘hard coded’. A couple of quick changes, and we were good to go.

The moral to the story? When using @DbLookup, make sure you don’t hardcode in your server name and/or database name. Replace “ServerName/Org:db.nsf” with “” (2 double quotes). That way, when you move the database to another server, you won’t have problems.

  • Isn’t it amazing how often we find things hardcoded? Yee-ow!

    I’ve had some databases that need to access other databases …on other servers. To avoid the hardcoding, one can simply create a profile document in the database. Include fields that will hold the server name and database filepath for each external db that might be accessed. Set the profile doc to only be editable by some role like “[DbAdmin]”.

    DbLookups and other code can then reference the profile doc for the database locations, and it’s very easy to change down the line by just editing the profile doc …without needing to tweak code.

  • Thanks for the tip, Joe. I’m going to add that bit of info to my ‘development’ arsenal.
    I’m starting to get so confident in my development skills that I think I may tackle coding again….