As per requirement, we need to convert the existing MS Access database to a web application. Is there any easy way to convert the MS Access database to web application? As of now they are inserting the data to access db using access Forms. User also wish to continue access form feature even if we create new web application for the same. That means user should have the option to access the MS access database through Access forms as well as web application.
Please guide me away to solve this issue.
Best Regards,
Ranish
You can use Office 365 and have somewhat of a web-based application.
https://blogs.office.com/en-us/2012/07/30/get-started-with-access-2013-web-apps/
Or, store Access in SharePoint, but your functionality will be quite limited. Keep in mind, no VBA will run on a web-based application.
The alternative is to use SQL Server Express, and ASP.NET, both of which are free from Microsoft. I'll tell you now, though, the learning curve will be quite steep if you have never used these technologies before. This combo, however, will give you the most control!
You can get the .NET framework from here.
https://www.microsoft.com/en-us/download/details.aspx?id=30653
You can get SQL Server Express from here.
https://www.microsoft.com/en-US/download/details.aspx?id=42299
Four years after and according to this:
https://www.comparitech.com/net-admin/microsoft-access/
still a question for many. Access can be converted to an Web App in almost no time. Particularly Access Forms are super easy to crate with the library like Jam.py.
The process was discussed on Reddit in April 2021:
https://www.reddit.com/r/MSAccess/comments/mj4aya/moving_ms_access_to_web/
I see quite a few Access databases with more than 100 tables, all converted successfully to SQLite3. After inspecting the imported tables via provided link, Forms are automatically created. Which leaves the Access Reports and Business Logic untouched. Reports can be designed in LibreOffice for Jam.py as Templates. Business Logic can be moved from VB to Python, if there is a need to do so.
The SQLite was selected as the default DB for the conversion, since it is very portable. Looks like the converted App can be moved to any DB that Jam.py supports, by Export/Import.
Cheers
First of all, Database and Web Application are not mutually exclusive.
Back to original question, I have done multiple projects like that. A client started with small Microsoft Access database with a couple of user; then they migrate to to web application when they get more traffic.
At first, you want to convert data from MS Access Database to SQL Server. MS Access Database is not meant to access multiple users simultaneously. Then you develop the Web Application which uses SQL server as back end database.
Right before you go live, you convert the data again from MS Access Database to SQL Server very last time. Then do not let them use old MS Access Database anymore.
Easy way to convert the MS Access database to Web application
Most of the time whoever created MS Access database are not software engineer, so table are not normalized and do not have relationship at all. I normally create new normalized database in SQL Server. Then write a small program to convert those data from MS Access to SQL database.
There are generally two approaches with more details covered in this article looking at ways to convert microsoft access to web application
Direct Port means simply a basic migration whereby you port more or less verbatim basic Access forms into a web portal i.e. Microsft Access to a browser-based version as is using a third-party tool. Some of these are quite mundane in that it just allows you to run the Access application inside an internet browser (whoopee!) or can be quite drawn out and then limits you on how much you can change afterward. With even more complex cases requiring a consultant to help you migrate the system. Though it does help to know your user count as the higher you tend to be, the less appealing a third-party porting service becomes due to subscription-based models.
Upsize -the more involved or complex your data structure is an upsize using custom development and splitting the system across web and data tiers might be worth it if
You've got a special process or some secret sauce you're looking to keep.
Likely going to have a significant user count and want to avoid subscription
Inherently cynical or cautious, and want to handle your own architecture and security
Looking for a specific user experience
If you mean how to convert automatically and you want to keep both Access and the Web application (I don't recommend that, I would move everything to the Web app) I would do the following:
Export your Access data in CSV/Excel
Use a platform like DaDaBIK to import the CSV/Excel file and automatically create a Web app based on that file, with data stored on SQL server, MySQL, PostgreSQL or SQLite.
connect your Access to the SQL Server (or Mysql, ...) database created by DaDaBIK, from now on Access will only be used as a frontend.
Now you have a web app created with DaDaBIK and your Access frontend both working on the same DB. As I said I would skip 3) and keep only the Web app, this helps with handling data integrity when two users are accessing the same record.
Depending on how complex is your Access Application (e.g. complex validation rules or custom VB code you added), you could reach your goal without any coding or with some coding.
Related
I'm building an application that will use a large database that's currently hosted on Azure SQL. I also want to use ASP.net Identity. Additionally, my local machine cannot connect to the Azure SQL database due to security restrictions (I can't remove these, they are corporate IT policies).
When developing, do either of the following make sense? Or is there another option that I'm unaware of?
Add the fields from the large database, and maybe a few rows of sample data, to my localdb that's being used by default by Visual Studio? If I do this, how do I migrate over to the existing Azure database when it's time to go live?
Host the development application on Azure. This wouldn't be ideal, given that I'd need to upload the application with every change.
You could do that for small scale testing and demonstration purposes yes. Essentially to interact with the database in ASP you create an instance of the database with the reference link to the local one. Providing they are identical, you could simply just change the link to the company database when it’s time to go live. You should be careful however as working with relatively small datasets means everything will run relatively smoothly and quickly but if your coding is sloppy, it could slow the entire thing down with big data sets.
As for developing, I would personally develop on a small scale yourself locally until you’re happy with the result. However, before you do a full scale launch, I would do a pilot launch in a small section to highlight any bugs you may have pushed and halt this on azure. Then after you’ve ruled out the obvious bugs, you’ve got a much safer launch.
to work in an develop-release separated environment:
you need a intranet copy of remote database first, then use code first approach to continue working,
reverse your database to code-first:
https://learn.microsoft.com/en-us/ef/core/get-started/aspnetcore/existing-db
https://cmatskas.com/scaffolding-dbcontext-and-models-with-entityframework-core-2-0-and-the-cli/
https://wildermuth.com/2017/12/20/Reverse-Engineering-Existing-Databases-in-Entity-Framework-Core-2
Enable database migrate: https://msdn.microsoft.com/en-us/library/dn579398(v=vs.113).aspx
Add identity framework to intranet database with code first: https://learn.microsoft.com/en-us/aspnet/identity/overview/getting-started/adding-aspnet-identity-to-an-empty-or-existing-web-forms-project
carefully maintenance migration code in later tasks, remote database will be auto-updated after your code is released
I am creating a c# wpf application that will store users information and allow users to view other users profiles in a corporation.
What would be the best way to store the data that each user is entering in order to have it accessible from a centralized location?
I'm fairly new to creating connections to databases in wpf applications and any push in the right direction would be greatly appreciated.
I've been reading a bit about SQLlite and it seems like it has its pros due to its mobile characteristics but does this mean that the SQLlite database will be local to each user? I need it to be centralized so that data entered from anywhere goes into one database.
Thank you
You could use ADO.net datasets to get the data from the server but this is done by downloading a local datatable and syncing it using a data adapter
connection between client and server
how to do in visual studio
As you stated mobile characteristics are not what you need. As for a central database consider the free SQL Express from Microsoft. You will need some type of security so they can only update their own profile.
Probably one of the more straightforward options is to create an Entity Framework model for your application. This may serve as a primer for your exploration of the topic:
Databinding with WPF
You'll probably find it easiest to develop against your local SQLExpress instance or some other local data store. But the final solution will need to be connected to an enterprise-ready database. Since there was no mention of cost constraints and the nature of this question is more of "how?" versus "what to use?", I see no reason why this shouldn't be a SQL Server solution.
Ultimately, though, this question is rather broad in scope and cannot be adequately addressed in a simple answer here.
In my application programming experience, I have always worked with a SQL Server (or Access) database on the back end that stores application data. I'm now looking at some business requirements that work with data that would fit well in a relational database, but they require it to be stored in a single, portable, custom file that the application will create, and load from. I know it's a very common concept for an application to save off a single file or document that it can later load and continue to work on, but I'm not sure how to achieve this with complex data. Encrypting xml comes to mind, but that would be very slow to work with or potentially eat up a lot of memory if I had to load it all back into objects first. What are some options?
I recommend you use a SQLLite or Firebird embedded database. There are other options as well. They support single-file usage and will give you a clear upgrade path for future versions of you schema (upgrade SQL scripts).
I did not understand how encryption plays into this.
When running in a .NET environment I think that SQL Server Compact is worth looking into. It is basically a mini SQL Server that doesn't have to be installed and configured as a service, but instead is an dll that you reference. You can use normal data access tools like linq-to-sql and entity framework.
SQLite comes to my mind. Its a single file based DB. Here is a link to convert SQL server databases to SQLite. Also check out Using SQLite in your C# Application
I am in the midst of writing a small program (more to experiment with vs 2010 than anything else)
Despite being an experiment it has some practical use for our local athletics club.
My thought was to access the DB (currently online) to download the current members and store locally on a laptop (this is a MS sql table, used to power the club's website).
Take the laptop to the event (yes there ARE places that don't have internet coverage), add members to that days race (also a row from a sql table (though no changes would be made to this), record results (new records in 3rd table)
Once home, showered and within internet access again, upload/edit the tables as per the race results/member changes etc.
So I was thinking I'd do something like write xml files locally with the data, including a field to indicate changes etc?
If anyone can point me in a direction I would appreciate it...hell if anyone could tell me if this has a name, I'd appreciate it.
Essentially what you need is, in addition to your remote data store, a local data store on your desktop. You could then write your code by hand to sync the data stores when you go offline / online, or you could use the Microsoft Sync framework to handle it for you.
I've personally used the Sync framework on a number of projects and once you get used to the conventions, it's pretty easy to use.
If a local storage format is what your after. SQLite is one option. You can copy your tables from the server to your local SQLite db.
You could also save your data to files, but XML is a horrible format for doing this. You'll probably want to use YAML or JSON instead.
You may want to take a look at SQL Server Compact -- it provides some decent capabilities with synchronizing back with the mothership SQL server.
If you're using MS SQL Server for production, and you only need to work offline on your personal computer, you could install MS SQL Server Express locally. The advantage here over using a different local datastore is that you can reuse your schema, stored procedures, etc. essentially only needing to change the connection string to your application (which you could run locally too through Visual Studio). You would have to write code to manually sync your online and offline db instances, but since it's a small application, it may be reasonable to just copy the entire database from production to local and then from local to production when you get home (assuming you're the only one updating the db, and wouldn't be potentially wiping out any new records entered in production while you were at the event).
Google Gears http://gears.google.com/ is intended if your app is a web app (which I didn't quite get what it is from your description)
What is the best way to store your Data outside of SharePoint. I want to use the default Edit/View options in SharePoint (though I do plan on extending their functionality). I need to store the data outside of the SharePoint Lists as I am expecting a large record set(150,000 to start with).
I totally agree with GalacticJello, storing data outside of the regular sharepoint content database is at the moment (MOSS 2007) a complete and utter nightmare. MS provided a ExternalStorage provider baseclas for us to override, but there are major cons against using this:
writing and using your own custom ExternalStorage provider implementation is doable, but very difficult
ExternalStorage provider implementations only do just that, making sharepoint store stuff in a different location than the regular content db.
This means that you would need to write your own code to keep the external storage and the list items in sync, and i'm not even mentioning workflows and versioning.
last but not least (and IMHO the worst), creating and using a custom ExternalStorage provider is not web app or site collection targetable, it's usage is farm wide (and there are NO workarounds). So any site collection you create in that farm will have it's doc libs use the external storage provider.
You can store the items in the list, the trick is to create efficient views that return paged data quickly back to the user.
Another option is to use folders to split up the data.
If you really need to store it outside of SharePoint, I would consider waiting for SharePoint 2010 and thier "External Lists" features, as there are a ton of pitfalls and things to consider if you want to mimic that functionality in SharePoint 2007 (been there, done that).
You could create a SQL Data source and use the Data Form Web part to connect it to an edit form etc.:
Data Forms and SQL Server, Part 1
Data Forms and SQL Server, Part 2
Personally I prefer to have the level of control of a totally custom web part.. with this you will not run into limitations eventually.
In this case it sounds like all the elements will be in the same list, otherwise SLAM (free tool on CodePlex) is a very neat data replication tool for related lists.
Based on the comments above it sure looks like a plain ol' ASP.NET page might be the best option, unless there is some good reason why SharePoint must be used.