0
votes

I have developed an MVC5 web application which uses Code First Migrations to build out the database. Now I am attempting to develop a mobile app (using PhoneGap if that matters) that exists as a native option to access the data of the application. However, I am having trouble finding a way for the databases to work nicely together.

Ideally, I'd like to use the same database schema entirely, and just have the application and the mobile app point to it. The database is hosted on Windows Azure. The issue I'm having is that with Azure, the standard way of handling databases with mobile apps is to use an Azure Mobile Service. However, when that service creates a database, it creates its own schema named after the service, whereas the web application uses the dbo schema. So the Users table might exist in dbo.Users for the web app, but in myAppName.Users for the Mobile Service.

I've already explored this solution, which seems to mirror my problem. However, there is an additional issue. The .NET MVC5 Authentication services use dbo as the default schema and there seems to be no way to change that.

Bottom line, if I use the default schema, the mobile app cannot access the database, but if I move the tables to the Mobile Services schema, the Login/Authentication fails because the tables don't exist in the default schema anymore.

Am I missing something here? It seems like it should be a fairly common task to have a web app and mobile app accessing the same database, but I've been investigating this for days without finding a solution.

Thanks for any help you can provide.

1

1 Answers

1
votes

The standard way of using a database for mobile apps in Azure is not Azure Mobile Services. I mean, I would not call it standard but just one of the options.

When Azure Mobile Services creates a database it does not create the database with its own schema. Azure Mobile Services does not have a predefined schema. You can define your own schema. The only predefined logic is the addition of the azure mobile services tenant name as a prefix to all table names. This is done to help you host multiple azure mobile service accounts in a single database. You can override this logic if you write the app in .NET. I'm not sure if that's possible if you roll a JavaScript based Azure Mobile Services account.

My suggestion to you would be to roll your own ASP.NET Web API project and host it in Azure. You can host in Azure Web Sites or Cloud Services according to your requirements. Once you have your own APIs running in Azure you should have no problem accessing the APIs from a web site or mobile app.

Hope this helps.