Last post Jan 15, 2018 03:51 AM by hkbeer
Jan 09, 2018 02:22 PM|hkbeer|LINK
I finished my asp.net web apps and put it on cloud server.
It has login function and store data database inside
App_Data folder with various functions consuming data of this database
I am thinking to invite customer to pay a fee to subscribe to such services from this web.
But I am facing a serious problem.
They like the function, but are unwilling put the data in a server not owned by them.
Then, I am unwilling to put my work on a server not owned by me.
So if you were me, how would you resolve this situation ?
In real world, which mode is more common, or there is a better way
or something in between to solve this issue ?
Jan 09, 2018 03:46 PM|ryanbesko|LINK
The customer provides access to a database server for you. You use the connection string and credentials they give you in your application. Same way our local web servers talk to SQL Azure.
Jan 10, 2018 05:32 AM|hkbeer|LINK
Thanks. I will try this path.
If the database is simply a flat file Microsoft Access database file (.mdb)
What is the easiest way ? Where can they store the file so they have rights but at the same time easier for me to retrieve ?
Jan 10, 2018 12:36 PM|XIII|LINK
please don't make use of Microsoft Access Database for a production application. It won't scale.
Basically what you're offering them is a SaaS solution. People use that every day: O365, SharePoint online, Uber, Facebook, LinkedIn, SalesForce, ...
Jan 11, 2018 12:50 AM|hkbeer|LINK
Thanks SaaS is like my need. I understand .mdb wont scale. My web apps doesnt handle transactional data and thus mdb is easier for me.
Given mdb is used, any efficient and easy way to store and easily be connected from my asp web app as a SaaS ?
Create another Cloud VM to store just a mdb file seems a lot too much work and cost.
What can I do ? Thanks
Jan 11, 2018 07:53 AM|XIII|LINK
it's not just the transactional part, what if you have a load of users on your service? You want to make money out of it so likely you want quite some users and scale out your SaaS solution.
What's the reason behind their question to be able to see/manipulate the data?
Another solution would be that you deploy your application on your server (for example on Azure Web App Services) and use one master database for all your configurations parts and internal stuff. Anything client related, their data, goes into another SQL
Database (also on Azure in the same data center otherwise the latency becomes too high) and connect to that depending on configuration you keep in your application. Make a tight contract with the client(s) that their database is their responsibility and if
something goes wrong it's their responsibiltiy. All you provide is the needed database scripts to set up their database so that your application can work with it. Otherwise make up a maintenance contract that you'll handle the upgrades etc and that they pay
a monthly flat fee for that. When a user of client X makes a request to your application you'll have to figure out in the application who it is and to which database it should go to grab the data.
Jan 15, 2018 03:51 AM|hkbeer|LINK
OK I will give up mdb and use some other SQL server solution. Thankns