I'm working through problems associated with moving a development system over to a production server. One of the things I've just run into is an error where the production server gacked on the datalayer=SqlServer component of umbracoDbDSN.
The interesting thing is that (a) the development server didn't have that element in umbracoDbDSN and (b) the production server was happily running >>with<< that element in umbracoDbDSN.
Now, I did do some major surgery to the production server in the course of trying to get it to work (major surgery == deleted all the files from the production website and uploaded the development website files). That included using a web.config file that was based on the one that was on the development server, which was configured to run under ASPNET 3.5.
I'm curious as to whether that might have resulted in an incompatibility with that datalayer directive. Just what does it do, and does it do it differently under ASPNET 3.5 and 2.0?
Cor, this is an old post! I was looking for general info on the umbraco datalayer keyword, as I know that's not a standard part of an ADO connection string, and umbraco uses that internally before removing it for any connection constructor.
I could be wrong about this, and given how long ago this post was, I expect it no longer matters, but is it possibly to do with the default membership provider maybe using connectionstrings[0] - i.e. "LocalSqlServer"? That's defined in the machine level web.config for the default membership provider, so If you have code that uses connectionstrings[0] anywhere, and a connectionStrings element in web.config that starts with a <clear/> I can imagine random scenarios where the default ASP.NET guts would try to connect locally using that connection string verbatim?
otherwise, ASP.NET 3.5 is ASP.NET 2.0 to all intents and purposes, and I'd have thought the difference was not to do with the runtime, but rather to do with the server config.
Soz, this is a guess, and it's an old post so feel free to ignore me :-P
Keyword not recognized: 'datalayer'
I'm working through problems associated with moving a development system over to a production server. One of the things I've just run into is an error where the production server gacked on the datalayer=SqlServer component of umbracoDbDSN.
The interesting thing is that (a) the development server didn't have that element in umbracoDbDSN and (b) the production server was happily running >>with<< that element in umbracoDbDSN.
Now, I did do some major surgery to the production server in the course of trying to get it to work (major surgery == deleted all the files from the production website and uploaded the development website files). That included using a web.config file that was based on the one that was on the development server, which was configured to run under ASPNET 3.5.
I'm curious as to whether that might have resulted in an incompatibility with that datalayer directive. Just what does it do, and does it do it differently under ASPNET 3.5 and 2.0?
- Mark
Cor, this is an old post! I was looking for general info on the umbraco datalayer keyword, as I know that's not a standard part of an ADO connection string, and umbraco uses that internally before removing it for any connection constructor.
I could be wrong about this, and given how long ago this post was, I expect it no longer matters, but is it possibly to do with the default membership provider maybe using connectionstrings[0] - i.e. "LocalSqlServer"? That's defined in the machine level web.config for the default membership provider, so If you have code that uses connectionstrings[0] anywhere, and a connectionStrings element in web.config that starts with a <clear/> I can imagine random scenarios where the default ASP.NET guts would try to connect locally using that connection string verbatim?
otherwise, ASP.NET 3.5 is ASP.NET 2.0 to all intents and purposes, and I'd have thought the difference was not to do with the runtime, but rather to do with the server config.
Soz, this is a guess, and it's an old post so feel free to ignore me :-P
is working on a reply...