[RESOLVED] What Could Go Wrong?

[Shaggy Hiker]

This actually works (mostly, and I'll know more after tonight), but it makes me queasy.

I am getting a download from a database that I have zero control over. What shows up is a big CSV dump of a complex view. Originally, whoever was putting that database together was pretty competent and consistent. There are five different downloads. The original three followed reasonable naming conventions. They weren't what I would have chosen, but they were reasonable and consistent. The latest two...have some oddities in them.

One field that surprised me was named "Date". Considering that Date is a data type, using that as a field name just seemed like a really bad idea. It works fine, but that doesn't mean it's good.

The field I MAY be running into issues with follows a convention that is unlike any other in the database, so I assume that consistency was abandoned as just a passing fad. The nasty thing they did with the field name was to include the units in the name, like so:

Weight(g)

Ignoring the fact that including the units in the field name is a bad idea, it seems like the parentheses could cause trouble. SQL Server may or may not have an issue with this. In testing, that field name caused no issue, but when I ran the same code in production, which happens around midnight, an error came back that the field didn't exist in the database.

The difference between the dev and prod is where and when the code is run, and that's it. It's the same code, dev runs on my computer, while the prod code runs from a server. The database written to is the same in both cases, because this data is too stupid to bother having a dev DB and prod DB. I won't get into all the things that are wrong with this process, it annoys me too much, but it is what it is, and the result is that there is only the one database.

So, my question is this: Is there something odd about having parentheses in a field name that could cause inconsistent behavior in an INSERT query? There will never be an UPDATE query on this data, so INSERT is the only one in question.

[dday9]

Do you have any control over the insert statement itself? If you do, then I'd just escape the column names to avoid any conflicts.

To be honest, I'm a little surprised that the parenthesis doesn't cause any issues in the first place, then again I have worked with some nasty database conventions and was pretty surprised at how flexible SQL Server specifically can be.

[Shaggy Hiker]

It's a simple insert, so I'm using a commandbuilder. I think that will automatically escape the field names, since it builds the command itself. I think it escapes EVERY name, needed or not. It works in testing, though, so that does appear to be working.

[Shaggy Hiker]

The insert failed again, at which point I left for vacation. I think I'll just rename that field, convert the incoming data to the new field, and try that...once I get home.

[RedHeadedLefty]

It's more likely just an escaping issue.

https://stackoverflow.com/questions/...s-in-sql-query

[Shaggy Hiker]

Probably. Fortunately, this is no longer my problem. I left it behind when I retired. That sucker was a millstone around my neck. I'm appalled by every piece of that project, database, and so on. Good people with good intentions got together and created the most horrid monstrosity.

[gigemboy]

That's called 'business'.