Closed ili closed 9 years ago
Why did you commented this part https://github.com/igor-tkachev/bltoolkit/commit/38f4dc95211fa78cedd5ae13ea23395851f5d4b9#diff-2c5efc6c798511e3d2dfcaf703bf038bR345 ?
it seems no need of this part - version detection would be done in anyway here https://github.com/igor-tkachev/bltoolkit/commit/38f4dc95211fa78cedd5ae13ea23395851f5d4b9#diff-2c5efc6c798511e3d2dfcaf703bf038bR430
It may breaks compatibility. Also what if I want to generate 2008 compitible SQL for 2012?
Do you think it to be a real use case? I'll look forward to save compatibility
DATABASE COMPATIBILITY_LEVEL?
I don't understand what are you about, SQL server db. property?
http://msdn.microsoft.com/en-US/en-en/library/bb510680.aspx
It can be set in sql server, so a new version maybe only understands old sql syntax!
Ok, we may check this parameter. Should checking be saved? :)
I don't know if you have the Right every Time on a database to read this Parameter! So maybe also Igor's old approach is necessary. (not for me indeed, but maybe for someone)
Just once, with caching details
no, i meant, maybe your db user is not allowed to read this parameter...
Automatic configuration is a good option, but it has to be one of options. We have no idea how many cases users can have.
@jogibear9988 from MSDN: The database to which the caller is connected can always be viewed in sys.databases (so we can allways read this parameter)
@igor-tkachev configuration string checking added
@igor-tkachev please review the issue, this is critical bug from my side and i do need nuget update =)
DataProviderVersionReslover added for an ability to resolve different DataProvider versions