Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
I currently have a simple Microsoft access database and I'm about to try to move to a full data entry web app. I could either do a Flask app (possibly hosted on Google App Engine) or a Meteor-js app (looking into Galaxy and Modulus). My concern right now is: it seems like it would be straightforward enough to write a python script to run through each row of the access database and create a new entry in an Sqlite database for example; but how could I do this to move from access to app engine's NDB or Meteor's MongoDB? Also if I do this, how difficult would it be to 'export' to an access database if necessary?
----------EDIT----------
So to be more specific: It will hopefully be a flask app hosted on Google App Engine and in theory (or at least to my understanding) it should be simple enough to run through the access database and create new entries in a MySQL database which from my understanding is what Google's cloud datastore is based in. Can anyone walk me through the actual steps of doing this, i.e. am I oversimplifying it in my head?
Most databases (including Mongo) have drivers that can expose row data as an ODBC driver. And also these databases have the ability to import text files (comma delimited or so called CSV in the Access world).
Since all of these database systems (including Mongo) have tools and ability to import the data, then you would simply export the data from Access and you done with Access.
As for exporting from Oracle, MySQL or Mongo (or anything else) into Access then the approach is usually the opposite of above. You simply export data as CSV and then import that data into Access.
There are few (if any) database products that can directly create an Adobe PDF file, or an Access database, or an Oracle database. So few if any products can no more create an Access database then say a MySQL database. (that’s not how the computer industry works in general).
So you can certainly export data and table data from most databases into a text format that in turn can be imported into say an Access database.
So in few cases the Oracle, or Mongo or any database system will not export to some other database, but exporting to some text format which can then be imported into the give database system is common, and usually such imports can be done without having to write code.
Also keep in mind that when referring to Access, there is a data engine part (the database) and then the application and UI part. The application part such as code, forms, reports in Access are NOT part of the database, but part of the application and it VERY VERY VERY important to distinguish between data in some tables which can be exported to another database and that of the code, forms/UI and reports which are application parts and code which MySQL or say a Oracle database does not provide. So moving the data is easy, but that does not move the code, user interface and program logic you may have created in Access.
Related
I've recently been hired on as an intern to take over a previous intern's Access 2003 Database. I have no prior experience in Access, and only a fundamental understanding of relational databases/SQL.
I'm looking to make the database faster, and more secure. Right now it's split on the network drive, with the backend database in a subfolder within the main project folder. It's being used by around 70 employees to take tests and store certifications. Several admins use it to create and print these tests.
It's extremely slow. The files are currently stored on a server several states away. If I transferred this database to Sharepoint, would it be faster and more secure? Is it worth the time and effort to do so?
The employees that use this database currently access it from a .exe on their desktop. Would sharepoint be more user friendly for them?
Alternatively, would moving the .mdb files to a closer server solve the speed problem? I'm currently using Access 2010. The forms are painfully slow to use as of right now.
Thank you
Moving the files to a local server would alleviate a lot of the speed concerns. Moving the file to SharePoint wouldn't do much different in terms of performance. But I'm assuming the files aren't local already for an unstated reason? Ideally, it should be moved to MS SQL server if you want to move the database, but that requires MS SQL knowledge.
Moving to SharePoint will only work if you up-size the data tables to SharePoint lists.
You cannot place the Access mdb/accDB file on SharePoint in some shared folder and have multiple users update at the same time. The reason of course is SharePoint files cannot accept “partial” writes. You have to "pull whole" file to client, update, and send whole file back. So this is not a possible setup with Access.
Access requires in multi-user mode that individual users can update “ONLY bits and parts” of the file at the SAME time. When you place a Word or Excel or in this case an Access file on SharePoint then the WHOLE FILE must be downloaded to the client. User then edits and then saves the file back up to SharePoint. So SharePoint is whole document based not file based like windows is. There is no NTFS file system - only a web based up/down file system (very much like FTP).
So SharePoint is a web based interface and Access requires the windows networking system + ALSO the ability to update bits and parts of the file (something SharePoint does not support nor any web site for that matter).
However if you move your back end tables out of Access and up-size the data to SharePoint tables (lists), then the Access front end clients can connect + edit that data. This is not much different in concept of up-sizing the data tables to SQL server.
So Access front ends can connect to an Access back end on a file server (your current setup), or connect to SQL server tables, or connect to SharePoint tables.
I explain how to up-size data tables to SharePoint in this video:
https://www.youtube.com/watch?v=3wdjYIby_b0
In some cases Access to SharePoint tables will run absolute circles around Access to SQL server. However in other cases such a setup will run SLOWER then SQL server. Only an experienced Access developer on a case by case basis can determine if SharePoint tables would be appropriate for your application. As the other poster points out adopting SharePoint or SQL server will require experience with those technologies along with likely a few good years of Access experience. Remember Access has a rather long learning curve – in most cases longer then say learning c++
In your case due to the Wide Area Network (WAN), then I suggest terminal services is your best bet.
I explain in easy to grasp terms as to why your setup now is slow in this article and what solutions you can adopt:
http://www.kallal.ca//Wan/Wans.html
I have a client/server application currently that has a Oracle 10G database. The company that I purchased the application form is not providing support. The company when I purchased the application provided me a SQL tool with a READ Only access access to approx 30-40 views.
Based on my analysis the views provide some but not all the data and I want access to data which may be in other tables
I am not a developer but the business owner so excuse my naivety in some of the questions below.
Can I export/duplicate/replicate the Oracle DB to another Oracle DB and will a Oracle DBA be able to view/access all the tables and understand the relationships
What is the best way to create a duplicate DB that keeps in sync with the application DB which we currently have. We would like to use the Duplicate DB as a backend for a website.
Thanks a lot!
ML
Assuming that the Oracle database resides on a server in your organization, it seems premature to be talking about talking about replicating the data to a different database. It is certainly possible to do so. But you can also run many, many different applications against the same database. Unless you know that the current database server would not be able to cope with the additional workload of the new application or you are planning on investing the time and effort to transform the data into better data model as part of replicating the data (which is extremely unlikely if you don't already know what the underlying data model is and if you don't already know that this data model isn't going to work well for the new application), you probably want to start with the assumption that you can probably build the new application against the existing database.
A database developer or a DBA should be able (again, assuming that you own the server) to determine what underlying tables exist. That person should be able to at least get some idea of how the tables relate to each other based on the existing view definitions. If the original company did a good job building the database, a new developer/ DBA should have a relatively easy time understanding the relationships. If the original company did shoddy work or was intentionally secretive, it will be a more challenging undertaking.
I'm currently working on an Intranet application project, using ASP.NET MVC 3.
One of the primary requirements is that all data created with the application must be available in the clients' ERP software as well; they work with MS Dynamics NAV. Accessing the data is not really a problem, as NAV uses SQL-Server as its database.
In fact I already have a working prototype, that uses Entity Framework for data access. The main issue here is that my company also develops quite a lot of custom functionality within the ERP, and thus some of the database tables I have to read from and write to often change. This would not really be a problem in a usual situation, but here, each and every field in the database is marked as not null, a very annoying feature of Dynamics NAV. That means that every field added to a table breaks my code, as Entity Framework tries to insert null when it doesn't know of a field.
Can any of you think of a solution that would not require regenerating the model after each change in the tables ?
Edit : Unfortunately our client still uses version 4.0 of Nav, so webservices are not an option.. I have already developed another application for them (part of a Warehouse management system which runs on mobile terminals), accessing SQL Server directly, but it was not quite the same scale.
If your requirement is to integrate with ERP like Dynamics NAV you should pass all data access through its application server. I think Dynamics NAV expose web services for communication with application server. Accessing its tables directly is way to disaster especially due to transactions and possible deadlocks. EF will make this even worse because you will not be able to tweak queries.
Application integration through database requires full control over SQL generated by all accessing applications.
The answer to your main question is no. The point of database first development is to regenerate your model after each database modification - especially if each database modification is breaking change (another reason why integration through database is not a good choice for you).
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
I was asked to provide an estimation to change a relatively small app designed with MS Access to use a SQL database.
First, is this even possible? I never worked enough with Access, so I'd like to know. If it's possible can you please point me to some websites with tutorials regarding this?
Second: if it's possible, is it recommended? Is it a big performance hit? Any specific do/donts that you can and want to share?
Thanks in advance for your help.
SQL Server upsizing is relatively easy to do although thorough testing is required. I'd estimate the effort at 5% to 10% of the initial system development. SQL Server upsizing is recommended in specific circumstances such as greater than 25 to 50 users or 24x7 access or difficulty/impossibility in rekeying data in the event of a corruption.
See my Random Thoughts on SQL Server Upsizing from Microsoft Access Tips page
There is a tool from the SQL Server group SQL Server Migration Assistant for Access (SSMA Access) which is a lot better than the upsizing wizard.
For the specific task of converting a Microsoft Access database to use SQL Server as the back-end data store while keeping the user interface from the Microsoft Access application, Access itself supplies an "Upsizing Wizard" (Tools | Database Utilities | Upsizing Wizard).
This wizard will step you through the process of connecting to an instance of SQL Server, creating an SQL Server database, and moving, to the greatest extent possible, your tables and views (called Queries in Access) to the new database.
The process can be relatively painless, or fraught with difficulty depending on numerous factors including how well you've validated your data in the Access database, whether you've made use of VBA functions in your queries, and whether you've used any query constructs unique to Access.
This tells you how to convert Access to SQL Server:
http://support.microsoft.com/kb/237980
Now, depending on how the application was written (language, etc.), the rest of it may be a quite a bit more work. However, it's really difficult to throw a ballpark on that one because the number of variables in this are large. In any case, it is possible, so that's not an issue.
In terms of performance, if the database is tiny, then Access may actually be faster. If the database is large, you'll gain from SQL server. Aside from that, you can have distributed clients and one data store centrally located, that's a plus.
By the way, if this is written using the .NET framework, it probably just got a lot easier.
This would be fairly easy to do (hopefully). In Access, you can create linked tables that are just links through to tables in other database (like SQL Server), so you could take your existing apps and replace all the Access tables with same-named links to tables in your SQL Server database.
I think doing this could be the opposite of a performance hit, depending on the circumstances. Access is very performant, but only with a small number of concurrent users (say, less than 30). So if the application has a large number of users, you would benefit from switching over to SQL Server. If, however, the SQL Server database is hosted on a different machine, than you lose performance by connecting to a database on a remote server (as opposed to connecting to a local Access database).
I wouldn't recommend doing this, personally.
to upsize or not to upsize - that is the question...(or was for us)
kind of a big deal to step up to sqlserver....we kind of dodged it by going to a WAN replication service from AccessTables.com and stayed with Access....at least for the time being.....the upsizing was just one issue...dealing with a web front end or terminal services was part of it too...
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
Is it possible to make my MS access tables as a centralised location for storing data
I have an mdb access file to store data into a table using a form.
Is it possible to enter data to a centralised location?
this mdb file copies are used by five user at same time
Please help !
Jaison,
You CAN use Access as your centralized data store. SQL Server is the OPTIMAL choice if you are just starting off.
But it is simply NOT TRUE that access will choke in multi-user scenarios.
It IS true that you need a good backup strategy with the Access data file. But last I checked you need a good backup strategy with SQL Server, too. (With the very important caveat that SQL Server can do "hot" backups but not Access.)
So my answer is different...you CAN do this so that by the end of the day today you can be deployed and multi-user. Then perhaps you should begin moving toward upfitting your current application to use SQL Server.
I recently answered another question on how to split your database into two files. Here is the link.
Creating the Front End MDE
This should get you started.
Seth
Five is a very small number of users and Access works very well for small offices, if it is set up properly. The database must be split, with each user having a copy of the front-end. This does not mean that each user needs a full copy of Access, the runtime version is sufficient. 2007 runtime is free (http://www.microsoft.com/downloads/details.aspx?familyid=d9ae78d9-9dc6-4b38-9fa6-2c745a175aed&displaylang=en)
You should read this thread that deals with many misconceptions: Is MS Access (JET) suitable for multiuser access?
I ran a 10 user split front/back end application for several years without any real performance problems, though it obviously depends on the size of your data and I agree that the optimal solution would be to use a proper database server.
Crucially though, SQL Server Express requires installation on a server, whereas an Access .mdb back end can sit on a network drive. If you are in a low-resource environment where all you have is a network drive, then an Access set up is a good solution.
We did in the end migrate the data to SQL Server and redirected the front end, but more for security and backup purposes (centrally managed).
I'm with Galwegian on this one.
Install SQL Server Express or better. You will need to make sure that it allows remote connections see (http://blogs.msdn.com/sqlexpress/archive/2005/05/05/415084.aspx).
Then you can either:
Create a new Access Project that
uses the SQL Server database as it's
backend
or
Use Link tables in your current Access database to link to
the equivalent tables in SQL Server
Once this is up and running you can start to think about creating Queries/Stored Procedures on SQL Server instead of having this functionality in Access.
I have seen access choking many times in multi-user setups.
Don't do it - use something like SQL Server Express instead and save yourself a lot of hassle
If you've only got 5 users and your tables are pretty small, simply store the .mdb file on a file server and you should be fine. (Splitting the database into frontend and backend is probably not a bad idea.)
If you have a lot of users or a shared fileserver isn't an option, you might be able to use the EQL Data plugin to replicate the data up to a central server, without having to go so far as setting up MS SQL.
Access is not the best database for sharing data but it can be shared between several users. See here
You can divide your Access application into two files, one with the user interface (ui.mdb) and the other one with the actual tables (tab.mdb). The code in ui.mdb needs to reference the tables in tab.mdb.
That way, you can store your tab.mdb on a network share, where all users (each with a seperate ui.mdb on their local drive) can use it.
That being said, I fully agree with Galwegian: Don't do it.
One of the problems with your approach is,
the query is performed on the client. A select foo from bar where fizz = buzz query needs to load all fizz entries in bar to check if the where clause is true.
His approach replaces the tab.mdb with a small database server. That way you can send a query to the server, which returns only the requested data sets, with much less network activity.