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.