Quote:
|
see what happens if you make a table with VARCHAR 100, 200, 400, 800, 1600 etc... and see if there is a cutoff point for the designer to make the field part of the search.
|
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.
I was just too lazy to add error handling all over my code to prevent color names or whatever from getting too long. I believe the VARCHAR(MAX) type will behave like any other VARCHAR type for size under 8KB (one page) in terms of performance so I never saw the point to limit the size of the fields. Am I circumventing best practices by doing this?
Quote:
ps that's one wierd looking opti query. Did the designer do that?
The oracle ones look very different, ORring is done first
|
Yes, this is the query as I just added the table to the designer. I didn't change anything. It would be simpler if it wasn't for my UpdateId and DisplayOrder nullable columns...
Anyway, I posted this question on the msdn forums and the answer was pretty much that it may be a bug or a by design decision. In any case, there's nothing to be done about it so I'll have to keep editing the queries manually and eventually remember to use Timestamp columns the next time I design a database.