I'm using Azure Mobile App service for the first time. I have an existing database which is hosted by Azure. I used this database when creating the App service. I followed this tutorial here which demonstrates how to use existing database. I first created the schema with the same name as the App service and then transferred all tables to that schema. Now I'm trying to access these tables from the Azure portal. I went to Easy Tables tab and created the tables with the same name as in my database and when I click into the table, I don't see any records that are already in the database. The new table that was created, doesn't have the same fields as the tables in my database. They have the following fields : "ID", "CREATEDAT", "UPDATEDAT", "VERSION", "DELETED". The tutorial I followed seemed to have worked for many people. I have the primary keys in my tables with the name "id".
Can anyone give me an idea what the problem might be?
The problem is that you followed a tutorial meant for Azure Mobile Services and applied it to Azure App Service - these are two totally different things. Probably most importantly, your tables are not in the [dbo] schema, which is where Easy Tables expects them to be (unless you configure the app service otherwise). In addition, Mobile Services used double-underscore before the system properties, whereas App Service does not.
If you want to use your existing database, follow the instructions in my App Service Mobile Apps tutorial here: https://shellmonger.com/2016/05/11/30-days-of-zumo-v2-azure-mobile-apps-day-19-asp-net-table-controllers/
Related
Recently observed that one can create multiple Service principals with the same name in Azure AD :
Note: They have different clientIds but same name. This in turn creates issues while creating users within Azure SQL.
So any reason why same name App Ids are allowed in AAD?
Also , a same client ID has different objectid when looked up via Enterprise applications and when seen via App registrations.
Is it because Enterprise applications is a union of all managed identities, Service principals etc , the objectid creation for Enterprise applications is different as compared to App registrations.
So any reason why same name App Ids are allowed in AAD?
Service principals and users in Azure SQL are totally different things. I don't think one is referential to the other. They designed it like this.
Generally speaking, when the value of a field is not allowed to repeat, it means that it is unique. I'm not familiar with Azure SQL, but it should follow this principle.
Why does Azure allows same service principal name? It's by design. In common scenarios, we mainly identify uniqueness based on its object id, which is globally unique identifier. Please do not use the name as the only condition for finding the service principal.
From a design point of view, we really should not create two service principals with the same name. It's a pity that Azure does not restrict this.
Also, a same client ID has different objectid when looked up via
Enterprise applications and when seen via App registrations.
An enterprise app and the associated app registration are two different objects, so they have different object ids.
The application id is actually the unique identifier for the app registration. It is just also shown in the enterprise app.
You can see Service Principal properties：
appId String The unique identifier for the associated application (its
appId property).
And the Application Properties：
appId String The unique identifier for the application that is
assigned to an application by Azure AD. Not nullable. Read-only.
On the azure page I can create my tables but there are only 4 data types and no option to create or relate the tables using foreign keys and SQL.
What I want to do is have a user and contact table with userId in contact table as a foreign key.
I am using apache cordova and angularJs on the front end in visual studio. I have already added the mobile service to my project.
Mobile Services does not directly support relationships in the backend, but you can customize the data using server scripts and the mssql object. Alternatively, you can create database views that have relationships between tables.
For an example of mapping relationships using database views, please see my post in this forum thread: Best Practice For Syncing Related Tables in Offline Mode.
For more information on managing the database directly, see this article: Scale mobile services backed by Azure SQL Database.
I use SQL Server and have a SSO Database that contain application role, and application permissions for several my organization applications. several web service created for this database and each application work with these services. I want to restrict my application to get only and only own data from SSO database. and can't view, insert, delete or change role and permission for another applications.
what's the best practice for this problem.
Can I use App_Name() or Program_Name() for this purpose.
thanks in advance
Don't give the app access to the tables, views etc, just make a well defined API using stored procedures.
I am working on a phonegap project to build a cross platform mobile app, and came to know from a website that the app's database can be deployed/built with "database.com".
The procedure is well explained but I have one question -
how to sync the database available on database.com with a database on a local server?
i.e. for e.g., if a client has his database (of his desktop application) on his local server and he requires a mobile app of the same now, what is the procedure to be followed in "database.com" to sync his server's database with the database on "database.com"?
PS: I need to use "database.com" for my database because I want to maintain it on cloud, and I do not have capability to maintain a local server.
You might need a service for data syncing if it is to be more than once. I work on a project that does exactly this.
www.overcast-suite.com
Otherwise, model your tables to Salesforce Custom Objects, export the data on the local server to CVS and use the Data Loader to import.
I have to use ASP.NET MVC 3 or above and SQL Server 2008. As per Multi-Tenant Data Architecture post, there are 3 ways to implement multi-tenancy
Separate Databases
Shared Database, Separate Schemas
Shared Database, Shared Schema
I have following details:
User should be able to backup and restore their data.
No of tenants : 1000 (approx)
Each tenant might belong to different domain(url).
It must support monitoring and management of tenants.
It must support user authentication and authorization for each tenant
It must support tenant customization(enable disable features set)
No of tables in each tenant: 100 (initial)
I would like to know what your experience says about which approach is more suitable for the project considering Economic and Security? Is there any good real time example(open source project) similar to this? I can use one dedicated server for the project.
Your requirement that users should be able to backup its data, can be achivable more easily with approachs 1 and 2... since it will be a native database task.
If you are in approach 3 (shared-shared), you will need to develop the logic to extract all the rows belonging to a single tenant and export it in a xml file or something like that. Then if you need to allow users to restore that backup file, you need to develop a restore logic.
I think this is the only requirement that could make you move away from #3.
Once you set your database using TenantID columns in your table... you can easily use one database for 1 tenant or a small group of tenants if your client is heavily concerned about security. For instance, you could have one database holding tenants that are not paying (free/demo accounts) and paying customers in another one. This way you are using approach #3, but being able to behave as #1 if you need it.
::: BONUS :::
AUTHENTICATION:
You will need to extend the SQL Membership and Role Providers used in your MVC3 app... so that a user login is valid only in the Tenant it belongs to.
MULTIPLE DOMAINS
Here you can see some approaches using ASP.NET MVC3 Routing:
MVC 3 Subdomain Routing
I would always use (3) Shared Database, Shared Schema.
If you want an example, how about Wordpress, Joomla, or any other popular open source web-based project?
Creating separate schemas or databases on a per-tenant basis will lead to massive management overhead. Not to mention increased complexity of analysing your data, costs, etc.
The only reason you'd go for (1) (or perhaps 2) is if you were to give your actual tenant direct access to some/all of the database. As you're using ASP.NET MVC 3, this isn't a consideration.