Quote:
Originally Posted by Stonkie
You are right, whatever length I make my VARCHAR, it always produces the right query except when it's VARCHAR(MAX). If the designer could not know what the type is, I think it wouldn't map to the String type correctly so we can rule this one out. I'm thinking this is a matter of performance, yet performance isn't an issue to me as my fields are rather short.
|
Given that VARCHAR(MAX) is up to 2 gigabytes, you can maybe see why it would be a design decision not to bother including string comparisons of this type
Quote:
|
Am I circumventing best practices by doing this?
|
It seems not, though if your varchars arent going to exceed 8kb you can reduce your optimistic sql headache and use varchar(8000) instead of varchar(max)
Quote:
|
I'll have to keep editing the queries manually and eventually remember to use Timestamp columns the next time I design a database.
|
Nothing stopping you adding a timestamp column, or a counter in a trigger. upon every insert set the counter 0, every update, increment it by one. Your optimism can then hinge on that counter being the same as when it was downloaded.. Very similar to a timestamp, i suppose