I have a simple ms sql 2012 express database & a simple VB Express 2010 application as its front end.
Can I simply host my MS SQL database on Azure & update the application to interrogate the hosted database? This would mean, the application would still be local, but the DB would be hosted. My offices are distributed & if we could do this it would save quite a bit of hassle.
Do I need to use a virtual machine, cloud services or straight hosting? Its difficult for me to understand the subtleties each service.
I've had a look at the azure services information and the documentation is pitched a little high for me. I just wanted to know if this is relatively simple thing to do & if anyone has has any pointers to How To's or Noob guides to azure.
It's absolutely possible and in fact, super easy to set up.
Check out this simple step-by-step instruction on how to set up SQL Server DB on Windows Azure - https://www.windowsazure.com/en-us/develop/net/common-tasks/sql-azure-management/
You can even connect to it from your SQL Server Management Studio just like you would connect to a local database or a database on your network.
Ideally - yes, you can change the connection string used by the VB desktop app to reference the Windows Azure SQL Database instance instead of the local database. That said, SQL Database is not 100% compatible with SQL Server. Be sure to check out the differences at http://msdn.microsoft.com/en-us/library/windowsazure/ff394115.aspx
Can I simply host my MS SQL database on Azure & update the application
to interrogate the hosted database?
Yes, your SQL Azure database is accessible via a connection string, but you have to make sure that you create a firewall rule in SQL Azure to allow your locally hosted or remotely hosted applications to access the database. Everything is turned off by default.
Do I need to use a virtual machine, cloud services or straight
hosting?
I'm not exactly sure what you're asking here, but a VM may be overkill, as that gives you basically a place to host a VM in Azure. You control the O/S, patching, etc. A cloud service (a web or worker role) is a little less maintenance heavy as the O/S, patches, updates, etc. are maintained by Azure and you just worry about your application. Straight hosting - are you talking about hosting on 1&1 or GoDaddy or something? If so, that's really no different than your VB app running locally and accessing your Azure database. For this option, just make sure you have your firewall rules set properly, otherwise you won't be able to access the database.
Hopefully this helps. Good luck!
Azure has some specific requirements that need to be met (like every table has to have a Clustered Index), and it does not support some functionality that is available on "normal" SQL Server (like replication, FILESTREAM data, or data compression).
Other than that, as long as your app meets the requirements, there should not be a reason for it not to work on Azure. The majority of the functionality not supported by Azure is most likely out6 of the scope of what a "noob" would implement, so you probably are safe.
However, Azure might be overly expensive for your needs. It might be cheaper to go for hosting the database somewhere. This would mean you would only have to change the connection string of the application to point to the new database server (though there could be additional limitations imposed by your hosting provider).
Good luck with whichever option you end up taking!
Related
I have built a CRM for my company using MS Access 2016, and we are looking to be able to use it remotely. I have currently split the database and have the back-end residing on our company server/shared drive. As I see it, we could put the back-end on SQL Server, but that would mean finding a way to host it. We recently moved to Google Apps for Work and I have been looking at the Google Cloud platform (e.g. Cloud SQL), but I don't know if it will integrate nicely with MSSQL. There's also Sharepoint, but we are are having difficulty even finding it to buy on Microsoft.com, and are trying to move away from Microsoft Office products anyway.
What would be the most stable, cost-effective, and fastest way to allow our employees to use our Access DB remotely?
My suggestion would be to migrate the database into SQL Server as step one. Then step two host the database in Microsoft Azure using the SQL DB service.
You can find more details and pricing here: https://azure.microsoft.com/en-us/services/sql-database/
Be sure you check the single database pricing. Unless you want the elastic scaling and performance.
I'm not sure about the cost part, but the fastest and most stable (IMHO) would be to use Remote Desktop. Either to a user's workstation or to a server set up for it.
We have migrated our backend to SQL Server from MS Access for obvious reasons. Our users access the front end off a VPS Hosted in the cloud. Connection string ODBC. It is robust and fast.
we are currently using a VPS. Looks cheaper and easy to access ;
https://clients.databasemart.com/aff.php?aff=275
I have a desktop app which uses a Firebird database. And it works fine, yet I want to also have access to that data online.
So I thought it might be possible to sync the data between Firebird and SQL Server. I know there is a tool called dbconvert but its quite expensive.
Any other solutions which come to your mind? Thanks!
You do not need to change the database. If you want to access your desktop app online you can, for example, place your desktop APP + firebird database on windows server and create a access through RemoteApp. Then you can accessed your application from anywhere (if the client OS can RemoteApp and online)
update
You can place application and database on a different type of server if you will reach them through some "remote desktop".
The solution consists of an SQL Database and desktop application working hard with that DB. DB Deployed as Azure SQL Database, application running on Azure Virtual Machine with Windows Server onboard. What is the deployment guidelines for this two services in Azure? I want to achieve max performance. Should they both be located in same resource group?
You will need to get your app and the database located as close as possible so yes the same resource group.
Make sure you do not have Mars enabled (MultipleActiveResultSets in connection string).
Make sure you do use connection pooling.
Read this to understand what you are dealing with:
https://www.simple-talk.com/sql/learn-sql-server/improving-the-quality-of-sql-server-database-connections-in-the-cloud/
Ed
How can I deploy Access applications to multiple companies, with linked tables to SQL Azure servers?
I'm planning to deploy the Access programs with Microsoft Access runtime, and I'm assuming that I'll need to include the odbc drivers as well? Is there a way to automatically have Azure create a new server when a company signs into my website and downloads a program, and have the Access program link to it? And is there a way to get around the IP address settings in Azure as well? Because companies will be using the programs on multiple PCs. Or is it possible to utilise that and charge per PC?
If you distribute the application pre-linked, then the user should not have to do anything to consume the data.
When using Access with SQL server you can in general use the standard windows built in SQL driver. However in the case of Azure you do need to download + install the native 11 drivers (so I recommend you use that driver during development and setup).
You can also have code include to re-link to the sql server, but as noted, if your application is “already” linked, then you really don’t have to do anything on application startup. Such re-linking would not be required every time the application starts, but only a “one time” re-link is required say if you’re going to change the database, or perhaps the user logon. How to re-link (DSN less) is outlined here:
http://www.accessmvp.com/DJSteele/DSNLessLinks.html
As noted, you really don’t need the above.
As for IP restrictions, in the Azure setup you can turn off such restrictions if you need a connection that will occur from any location, but that does open up a security hole. (when you first create the SQL database you will be prompted for firewall rules).
All of the above assumes you been developing that Access application with SQL server as the back end (you can even use the free edition of SQL express for development on your local machine).
Last but not least:
Because your connection is occurring OVER the internet, then you speed will be MANY times slower then using a local server. Read the following article to get a “grasp” of this speed difference:
http://www.kallal.ca//Wan/Wans.html
So MUCH additional work is required in Access to obtain good performance when your connection is OVER the internet as opposed to SQL server running on your local network.
I was readin this month edition of SQL Server Magazine and in an article about securing Sql Server environment , the author mentioned that developer should try to have the website and the databases run in separate servers for security. I have a shared hosting account and was wondering if it makes sense to buy a second account to move all databases there. Or does it only make sense when using dedicated servers? How would it affect performances on my website?
I use asp.net and have a hosting account with DisountAsp
That article probably doesn't apply to your situation. Running the database on a separate server is a measure to protect against root compromise of the web server hosting machine. I a shared hosting environment the same situation would result in compromising all accounts on that machine anyway. Depending on the particular settings of your hosting, your account database may alreayd be on a separate server.
Besides, with a shared hosting account is very unlikely you'll even be able to query a database from another account.
If you buy a second server, what will it be, a VPS? I imagine you will get more CPU cycles on a VPS with a dedicated database server than a dedicated machine with multiple databases, but who really knows.
Still, your host isn't running websites on their shared database servers, so what's the difference, security wise?
Performance would me my number one driving factor. I mean if someone compromises your web server, unless your connection strings are encrypted, they've got what they need to connect to the DBs.