For what it's worth, a warning to folks who use a shared hosting site provider that uses the Parallels Plesk Control panel for site administration.
I use DailyRazor.com. Their Plesk Control Panel for site maintenance is by an entity called "Parellels".
The other day I went into the control panel "Parallel Plesk" and opened up the ASP.Net settings to check the session timeout value. One of the many fields on this multipurpose screen is in a section called "Connection String Manager" and tries to show the
current connection string(s) so you could, if you wanted, edit them in that screen.
Unbeknownst to me, it turns out the designer of that screen apparently arbitrarily decided that 150 bytes was more than enough for any connection screen and set that as the max length of the connection string. This "fact" was not announced anywhere in the
app.
The only change I made was to an unrelated section of the screen, the session timeout variable. After I made my change to the session timeout variable, I clicked on OK and went about my business. That is until one of my users complained about a connection
string error.
It seems that when I clicked "OK" on the ASP.Net Settings screen, all values populated in all fields of the screen were used to replace/update matching types in the web.config file of my site. This included the connection strings. However, my connection
string (being one of those nasty Entity Framework monstrosities) started out life as a nice, fat 325 byte string. The helpful ASP.Net settings app replaced my working 325 byte connection string with the first 150 bytes of its original version. Needless to
say, ASP.Net was not happy with the result.
It took me the better part of 2 days to find out what was the cause. The tech support folks at Daily Razor were pretty much clueless (I do not believe they even knew about the special form of connection string that Entity Framework requires).
So if you ever have a similar connection string problem and you KNOW you made no changes to the connection string, this may be of some help.
rrrsr7205
Participant
1304 Points
313 Posts
Shared Hosting - Plesk Control Panel - Truncates Connection Strings in Web.Config
Nov 07, 2012 06:15 PM|LINK
For what it's worth, a warning to folks who use a shared hosting site provider that uses the Parallels Plesk Control panel for site administration.
I use DailyRazor.com. Their Plesk Control Panel for site maintenance is by an entity called "Parellels".
The other day I went into the control panel "Parallel Plesk" and opened up the ASP.Net settings to check the session timeout value. One of the many fields on this multipurpose screen is in a section called "Connection String Manager" and tries to show the current connection string(s) so you could, if you wanted, edit them in that screen.
Unbeknownst to me, it turns out the designer of that screen apparently arbitrarily decided that 150 bytes was more than enough for any connection screen and set that as the max length of the connection string. This "fact" was not announced anywhere in the app.
The only change I made was to an unrelated section of the screen, the session timeout variable. After I made my change to the session timeout variable, I clicked on OK and went about my business. That is until one of my users complained about a connection string error.
It seems that when I clicked "OK" on the ASP.Net Settings screen, all values populated in all fields of the screen were used to replace/update matching types in the web.config file of my site. This included the connection strings. However, my connection string (being one of those nasty Entity Framework monstrosities) started out life as a nice, fat 325 byte string. The helpful ASP.Net settings app replaced my working 325 byte connection string with the first 150 bytes of its original version. Needless to say, ASP.Net was not happy with the result.
It took me the better part of 2 days to find out what was the cause. The tech support folks at Daily Razor were pretty much clueless (I do not believe they even knew about the special form of connection string that Entity Framework requires).
So if you ever have a similar connection string problem and you KNOW you made no changes to the connection string, this may be of some help.