Friday, March 30, 2012

Resorting Columns

Here's something I've never run into before, and I hope someone can help.
I have two identical SQL2000 databases (DB1 and DB2). Each has a different
name and is part of a different merge scheme. My developer has an
application that writes data from a table in DB1 to an identical table in
DB2, but it's failing. He says that it's because the columns in one table
aren't in the same order as the columns in the other table. E.g., one table
has column19 in the 19th position, and the other table has column19 in the
15th position.
Is there a way to move a column from one position to another without
removing the databases from replication?
I'd really appreciate some help in this.
Thanks,
John Steen
Developers should never ever rely on the column order. Tell your developer
to stop being lazy and specify the columns in the insert statement. If he
doesn't he will introduce some very subtle bugs over time that will be nearly
impossible to track down. I made the same mistake at my first job while I
was still in college and still regret it.
|||Thank, Scott, I'll definitely pass that along to our developer.
Unfortunately, I don't think it's going to fly this time. We're trying to
piece together a quick solution for a short-term problem that will be going
away by the end of the month. He's not going to want to rewrite all his apps
just for that. If there's a way for me to change the position of the column
in the table so the app will work, I'd rather do that.
Thanks,
John
"Scott S." wrote:

> Developers should never ever rely on the column order. Tell your developer
> to stop being lazy and specify the columns in the insert statement. If he
> doesn't he will introduce some very subtle bugs over time that will be nearly
> impossible to track down. I made the same mistake at my first job while I
> was still in college and still regret it.

No comments:

Post a Comment