Okay, as I said in my last post, I see a lot of posts in forums and newsgroups dealing with web development that are somewhere along the line of the title. And it may be GoDaddy, or it may be some other shared hosting company.
I started writing this post about a week ago, and trying to recount my experiences chronologically became too long and rambling, so let me just list some of the problems that I have encountered. I may expand on some of them in future posts.
1. You don't have control of your execution environment on a shared hosting service like you do when you're running on your own machine. You don't have control over what software has or hasn't been installed, or what the machine configuration settings are, etc. The first problem I encountered was that I had installed the MySql Connector that interfaces the .NET framework to a MySql database. GoDaddy hadn't, or at least didn't have the same version that I had and that my program was expecting. (And they couldn't or wouldn't tell me what version, if any they did have.) The work around is to make sure your program/website is completely self-contained, so that you're not relying on anything on their environment (in my case, by copying the MySqlData.dll into the "bin" directory of the website I was publishing to GoDaddy).
2. You're running in what is known as a "medium trust" environment in a shared hosting server. Chances are, unless you have deliberately configured it, your development and test environment is a "high trust" environment. What this basically means is that there are a whole lot of perfectly legitimate things that your program might want to do that are simply not allowed in the medium trust environment. This is worth a whole post of its own, but just let me say that, if you're going to be hosting your site on a shared hosting server, set up your development and test environment for medium trust (I'll cover how in another post. For now, if you need to know how, google it.) You will save yourself a whole lot of headaches.
3. The database servers are probably different in some respects from what you're running on in development. This will be particularly true in the case that you're using MySql (which I was), rather than Microsoft SQL Server (MSSQL). There are two noticable differences, even though I was running MySql in my development environment as well.
One is that the MySql server that was in my development environment was running on a Windows machine. There's is running on a Linux server. Yes, the web server is hosted on a Windows machine, but the database that it connects to is running on a separate machine which is Linux. The key difference is that MySql on Windows is not case sensitive, while on Linux it is. So a command like "SELECT productID FROM Products WHERE Sku=@Sku" will work fine on a Windows base MySql Server, even if the columnname is actually productid and the table name is products. But it will fail if that same database is hosted on a Linux server.
The second area of concern is that the security is much tighter on GoDaddy's database servers. Specifically, you cannot access anything outside of the database you're connected to, even if you have permissions for it (I'm not sure how you would specify permissions for it.) As a result, you are not even permitted to specify the database property of a table. If you're not aware of it, this can be a problem, because the MySql Connector that interfaces with Visual Studio, by default, generates insert, update and delete commands that reference the tables as <databasename>.<tablename> (E.g., INSERT INTO MyDB.Customer (CustomerName, ...) ) Even though the databasename is, in fact, the database that you are connected to and working with, simply specifying the database name will kick the statement out on a permissions violation. (The first time I saw this error, it said something like my Insert statement failed because I didn't have proper permissions, and I was on the phone complaining irately to GoDaddy Support that they had set up my database without giving me write access into my own tables! It took me a while to understand exactly how it worked.)
Another area where this comes into play is that, when you're dumping and restoring a database, you may have to edit the SQL that's generated to remove certain parameters. When you define a View, the MySqldump will dump the CREATE VIEW statement with a "DEFINER" attribute. Even though the DEFINER is you, that will cause the statement to fail if you try tor use it to restore the database on GoDaddy's servers.
Also, GoDaddy, allegedly for "security reasons" will not permit you to define your own stored procedures in your database (and don't tell you that until you try it and it fails with some obscure error!). I'm not that good with databases, and so far, I've only had one instance where I was trying to use a stored procedure. Fortunately, I was able to program around that one fairly easily.
So, those are the three main areas. There's probably some small incidents here and there that fall outside those bounds. But that covers most of it. And there are ways to work around all of them. It's just a question of how much work you have to go through to do it.
I will try to expand on the "medium trust" issue in another post.
I started writing this post about a week ago, and trying to recount my experiences chronologically became too long and rambling, so let me just list some of the problems that I have encountered. I may expand on some of them in future posts.
1. You don't have control of your execution environment on a shared hosting service like you do when you're running on your own machine. You don't have control over what software has or hasn't been installed, or what the machine configuration settings are, etc. The first problem I encountered was that I had installed the MySql Connector that interfaces the .NET framework to a MySql database. GoDaddy hadn't, or at least didn't have the same version that I had and that my program was expecting. (And they couldn't or wouldn't tell me what version, if any they did have.) The work around is to make sure your program/website is completely self-contained, so that you're not relying on anything on their environment (in my case, by copying the MySqlData.dll into the "bin" directory of the website I was publishing to GoDaddy).
2. You're running in what is known as a "medium trust" environment in a shared hosting server. Chances are, unless you have deliberately configured it, your development and test environment is a "high trust" environment. What this basically means is that there are a whole lot of perfectly legitimate things that your program might want to do that are simply not allowed in the medium trust environment. This is worth a whole post of its own, but just let me say that, if you're going to be hosting your site on a shared hosting server, set up your development and test environment for medium trust (I'll cover how in another post. For now, if you need to know how, google it.) You will save yourself a whole lot of headaches.
3. The database servers are probably different in some respects from what you're running on in development. This will be particularly true in the case that you're using MySql (which I was), rather than Microsoft SQL Server (MSSQL). There are two noticable differences, even though I was running MySql in my development environment as well.
One is that the MySql server that was in my development environment was running on a Windows machine. There's is running on a Linux server. Yes, the web server is hosted on a Windows machine, but the database that it connects to is running on a separate machine which is Linux. The key difference is that MySql on Windows is not case sensitive, while on Linux it is. So a command like "SELECT productID FROM Products WHERE Sku=@Sku" will work fine on a Windows base MySql Server, even if the columnname is actually productid and the table name is products. But it will fail if that same database is hosted on a Linux server.
The second area of concern is that the security is much tighter on GoDaddy's database servers. Specifically, you cannot access anything outside of the database you're connected to, even if you have permissions for it (I'm not sure how you would specify permissions for it.) As a result, you are not even permitted to specify the database property of a table. If you're not aware of it, this can be a problem, because the MySql Connector that interfaces with Visual Studio, by default, generates insert, update and delete commands that reference the tables as <databasename>.<tablename> (E.g., INSERT INTO MyDB.Customer (CustomerName, ...) ) Even though the databasename is, in fact, the database that you are connected to and working with, simply specifying the database name will kick the statement out on a permissions violation. (The first time I saw this error, it said something like my Insert statement failed because I didn't have proper permissions, and I was on the phone complaining irately to GoDaddy Support that they had set up my database without giving me write access into my own tables! It took me a while to understand exactly how it worked.)
Another area where this comes into play is that, when you're dumping and restoring a database, you may have to edit the SQL that's generated to remove certain parameters. When you define a View, the MySqldump will dump the CREATE VIEW statement with a "DEFINER" attribute. Even though the DEFINER is you, that will cause the statement to fail if you try tor use it to restore the database on GoDaddy's servers.
Also, GoDaddy, allegedly for "security reasons" will not permit you to define your own stored procedures in your database (and don't tell you that until you try it and it fails with some obscure error!). I'm not that good with databases, and so far, I've only had one instance where I was trying to use a stored procedure. Fortunately, I was able to program around that one fairly easily.
So, those are the three main areas. There's probably some small incidents here and there that fall outside those bounds. But that covers most of it. And there are ways to work around all of them. It's just a question of how much work you have to go through to do it.
I will try to expand on the "medium trust" issue in another post.
Walking with God: Talk to Him. Hear from Him. Really., by John Eldredge
Posts
No comments:
Post a Comment