I am trying to determine the best approach when designing a new Access based application. Due to decisions made by others I have to use Access 2003 as my front end and SQL Server as my back-end data store (I would have preferred to use Winforms/WPF and SQL Server 2008 but that is another story).
Originally I was thinking of using Access Data Projects (ADP) as data security is a big issue in this project and ADPs would allow me to store everything (except VBA. reports, and forms) within SQL Server. Problem is that many developers I have spoken to suggest that using ADO is something that Microsoft has tried and then abandoned. They suggest using linked tables will provide a more consistent and less buggy experience.
I was hoping to get some feedback on what others think the best solution might be. Additionally, I would be interested to know if others consider linked tables to be a security risk over ADP. Thanks for any assistance.
Edit ... just wanted to add that the number of people using this application will be small (10 to 20). I should also add that this application is being developed from scratch. No conversion is needed.
ADPs have had no significant features added in a number of versions now. They also have some quirks compared to MDB/ACCDBs. There are probably less than 1% of the folks using ADPs who use MDBs/ACCDBs so support is much better for MDBs/ACCDBs.
The ADO part is immaterial as you can use either ADO or DAO.
If you use Windows authentication then there is no real difference between ADPs and linked tables as userid and passwords aren't stored in the linked tables metadata.
The number of users is immaterial. There is no reason why you couldn't have thousands of users in an Access FE against a SQL Server BE.
Related
I have a question regarding the best solution to adopt for a client. My client has an existing Access
database with tables, queries, reports and lots of them! He requires an application/solution that will :
allow it to be used online/cloud.
allow the application users to login and access only their record data.
allow my client to have a main-admin account to login too and adminster all client accounts.
allow the application users to add a text box via a form to add a new field to the table
allow application users to upload documents against a record
Heres my dilemma; as a PHP/Open Source developer i could write an application which does all of this; having already used a 3rd party program to convert his Access dB to MySQL (though i will have to manually convert the Access Queries forms to MySQL Views.
This is my preference since i have total control and confidence with the dev tools i'll use. Down side is it will take absolutely ages because of the number of tables and queries. Alternatively, i recently read about MS Sharepoint which i know nothing about other than what i read. SharePoint looks like it could handle this solution very easily especially the MS Access stuff, Microsoft now
as of 2018 recommend using 'PowerApps' for building Access Apps in sharepoint. It all looks quite do-able but i'm not a MS aficionado and dont want to get in 'out-of-my-depth'.
Having done (and enjoyed) many years of MS VB development up to about 5 years ago, i know Sharepoint will allow you to work at a level which requires less Programming skills and more Power-user skillsets.
Can any one advise which they think would be the best route, im not asking for the finite detail - just a pointer from anyone that uses Sharepoint and knows its capabilities beyond the little i've read. Im looking to invest some time into learning it for future projects as it looks great; but for this project isnt it a little to simple???
Many thanks
Access is a Windows application - and therefore not browser based. There is no port to html technology - it is a complete re-write.
For geographically distance users - as with any Windows application - the available solution is the Remote Desktop technology.
It is / would be unusual for any application to allow the end users to redefine the table structure. Thus the idea of adding new fields to a table is not feasible but perhaps one is using the wrong terminology and intends instead to be adding new records to the table - which would be routine.
The other features are all do-able in Access.
For years we've seen users wanting a magic transform from their Access Windows application to a web based application. It simply does not exist.
I'm writing the entire database system for a factory, this includes inventory, payroll, incoming and outgoing shipments, job-data, customers, etc. The database will be stored offsite on a server running Windows 2008 R2 with SQL 2005. The guy who runs the server sent me this too:
"We also have quickbooks installed on the server and we have Exchange 2010 running. The terminal server is also ws 2008 R2.
There is plenty of horsepower on the primary exchange/file server. Let me know if you have any other questions.".
I know my boss uses Quickbooks to look at reports and stuff like that. I'm not sure how relevant exchange 2010 is, nor what the significance of "terminal server is also ws 2008 r2" is. My boss wants me to write the entire system in ms access 2010, but I feel like this will be a lot more work than simply writing it in MySQL. Will my boss still be able to look at his reports in quickbooks if we change the database to MySQL? What would be a good database technology to use? I feel the most comfortable writing it in a scripting language using MySQL, but would still be happy if I could write it in something like C/C++. I've been trying to learn access, and it seems that setting up a front-end and back-end database in access would be a pain in the ass. There are going to be several sectors in the factory that will be using the client-side software to run queries and insertions into the database(I think around 5-6).
If I can write this thing in MySQL, I think I could do the whole thing fairly pain free, but I fear that I can't because it will be incompatible with Quickbooks and the previous database(Although I hear converting is fairly easy). Mostly just Quickbook compatibility is my problem.
How horrible would it be to write this thing in Ruby?
Thank you, any help is greatly appreciated.
I don't mean to be a spoil sport but there is a tremendous amount of naivety expressed in this question. It's hard to imagine that you will be successful in designing and implementing such a large system without a basic knowledge of the technologies involved.
A few thoughts:
Quickbooks already covers most of the features you say you will be responsible for implementing. Are you supplementing the existing Quickbooks system, replacing it, or what?
Quickbooks uses its own (extraordinarily slow) database engine. It isn't "compatible" with SQL Server, MySQL, or Access.
SQL Server 2005 is a database. You don't use a database with it, you use it as your database. A Microsoft-centric organization such as the one you describe is not likely to be interested in installing yet another database server like MySQL.
MS Access encompasses both a database "engine" (called JET) and a desktop development environment. The engine can be used with other development environments and the development environment can attach to other database engines (most often SQL Server, but others work too). When you say the boss wants to write the system in MS Access you need to be clear whether he means the engine, the development environment or both. (My guess is they want to use Access as the front-end development platform and SQL Server as the data store).
You will not write a system of this complexity in a month. You probably won't even design it in that time.
Quickbooks can use MySQL as a datasource (or just about anything else), but you'll need to make your database conform to the Quickbooks way of doing things: i.e., your tables will need to match the QB table structures. It sounds like you just need a front end (data entry forms and reports) and a custom back-end. Access can quickly turn into a nightmare if you don't put in some up-front design thought, but it does give you forms & reports & web pages free in a neat little package. Make sure you use an Access Data Project (adp) that's connected to a SQL Server back end. Access does have its own native database, but everything gets stored in one local file and it's not good for applications that will be accessed by multiple people in multiple locations. It also gets complicated when you need to make a change and roll it out to all of your users.
Another option is to look into a customizable web platform, like SalesForce or MS Dynamics. That will also let you create your own tables, forms, and reports, and updates are immediate for all users, but you'll have ongoing monthly user fees. They look great on a resume, though!
I would like to design a database application using Microsoft Access. Before I start there are some important features I want to make sure are available in Access.
In a multi-user environment can the database be accessed simultaneously by different users such that only individual records are locked/unlocked as necessary?
Does Access need to be "opened" or can a "front end" be designed so the user only sees menus, menu bars, tabs, data screens, etc?
Can the database design features be locked so the user cannot change any database features?
Thank you for your help.
AF
Yes, certain records can be locked.
For Example, if you work with an ADO Recordset:
recordset.Open Source, ActiveConnection, CursorType, LockType, Options
LockType defines the locking-mechanism used for the selected Query Source.
More Information on that: http://msdn.microsoft.com/en-us/library/ms675544%28v=vs.85%29.aspx
Usually you split your Database into an frontend and backend. The back-end only contains only the tables, the rest goes in to the frontend. The backend tables are then linked to the frontend. Here is a link explaining how to do that: http://www.fmsinc.com/MicrosoftAccess/DatabaseSplitter/
In the frontend file can be compiled, so that the frontend users cannot edit sources.
In response to the third of your initial questions please note that Microsoft Access offers the facility to convert an Access database to an executable file (having file extension "accde" where your forms, reports, code and macros are protected to a substantial extent. However the level of protection offered with regard to tables is low in that the same are directly accessible even in an accde. MS Access also offers the runtime version free of charge and does not restrict its deployment to as many users as you may require. It no longer offers user-level security. This feature has been replaced with an encrypted password feature. Thus you will have to insert your own design and code to impose access restrictions on different categories of users. Alternatively, to use the user level security feature, one has to develop his application in an earlier version of Access in which this feature was available and thereafter use a recent version to convert it. I am uncertain whether MS Access 2013 will entertain such a database but understand that MS 2010 will though it will not offer that feature when you create a new database inside it.
You can get SQL Express for free, it's a stripped down version of SQL Server. It will handle multiple user access significantly better and not come with the bloat/performance degredation issues that Access brings along.
There will be a slightly higher learning curve, but if you're looking to get your foot into the development world's door, you'll be much better off learning how to work with SQL Server than Access.
Am considering moving my simple ms-access 2003 client server desktop application to one with an ms-access interface and sybase 10 or 11 sql Anywhere backend database.
Why? because i want to:
- take advantage of the easy & quick way access can build forms and reports (which i am already familiar with ... meaning less learning curve for me)
- take advantage of the reliable and efficient way sybase dbs can be set up to synchronize data across various types of networks using mobilink.
I dont want to use access replication because the data will eventually grow to more than 2GB in the back end.
So,
- What are the Pros & cons of this approach?
- can i just link to the sybase database tables using a DSN or connectionstring in VBA and proceed?
- will navigating and updating/deleting records through the ms-access forms need any special considerations?
thanks for the help
Having done both, I can heartily recommend the linked table option as preferred.
In the past, I've worked with Access frontends to MS-SQL Server backends. In the main, it's the same as working with local access tables, but there are a few exceptions. I've not worked with SQL Anywhere, but MS_SQL had issues with things like Autonumber fields for instance (different behavior to Access).
I've also recently worked on an Access frontend to a MS-SQL backend, where the normal access connection methods weren't used, in favor of Table-based-functions and stored procedures...this was an absolute nightmare to code, and pretty much offset all of the upsides to working with Access as a Rad tool. If I were to do this again, I would instead insist on forgetting about Access, and using VB.Net for the frontend. Given how good MS Report Server is these days, there really is very little reason to use Access any more.
Yes, you should be able to use ODBC linked tables to your Sybase database, assuming Sybase provides compatible ODBC drivers. However, I'd suggest not using a DSN, but a DSN-less connection instead. What I do is have a DSN defined on my programming PC, and after linking the tables, I run Doug Steele's code to convert to DSN-less connect strings.
The app should mostly just work, but there are some things that may need tweaking. Don't expect any performance improvement -- indeed, it's more likely you'll lose performance. You can then examine the parts of the app that aren't performing well and evaluate how to make them work better with a server back end. Usually this involves creating views on the server, or writing stored procedures (for things such as inserting or updating records), or using passthrough queries (so that Jet doesn't touch the SQL and just passes it off to the server for execution).
This can be complicated, though I found out that it wasn't as hard as I expected the first time I ever upsized.
Two users wanted to share the same database, originally written in MS Access, without conflicting with one another over a single MDB file.
I moved the tables from a simple MS Access database to MySQL using its Migration Toolkit (which works well, by the way) and set up Access to link to those tables via ODBC.
So far, I've run into the following:
You can't insert/update/delete rows in a table without a primary key (no surprise there).
AutoNumber fields in MS Access must be the primary key or they'll just end up as integer columns in MySQL (natch, why wouldn't it be the PK?)
The tables were migrated to MySQL's InnoDB table type, but the Access relationships didn't become MySQL foreign key constraints.
Once the database is in use, can I expect any other issues? Particularly when both users are working in the same table?
I know this topic is not too fresh, but just some additional explanations:
If you want to use MS Access effectively, especially with bigger, multiuser databases, please do the following:
split your MDB into frontend application and backend (data only) files - you'll have two separate MDB files then.
migrate all the tables with data and structure into external database. It can be: MySQL (works very well, no database size limitations, requires some more skills as it's not MS technology, but it is a good choice in many cases - moreover you can scale your backend with more RAM and additional CPUs, so everything depends on your needs and hardware capabilities); Oracle (if you have enough money or some kind of corporate license) or Oracle 10g XE (if this is not a problem, that the database size is limited up to 4 GB and it will always use 1 GB of RAM and 1 CPU), MS SQL Server 2008 (it's a great pair to have MS Access frontend and MS SQL Server backend in all the cases, but you have to pay for license! - advantages are: close integration, both technologies are form the same vendor; MS SQL Server is very easy to maintain an effective at the same time) or Express edition (same story like with Oracle XE - almost the same limitations).
relink your MS Access frontend with backend database. If you selected MS SQL Server for the backend then it will be as easy as to use the wizard from MS Access. For MySQL - you have to use ODBC drivers (it's simple and works very good). For Oracle - please do not use the ODBC drivers from Microsoft. These from Oracle will do their work much better (you can compare the time needed to execute SQL query from MS Access to Oracle via Oracle ODBC and MS Oracle ODBC drivers). At this point you'll have solid database backend and fully functional MS Access frontend - MDB file.
compile your MDB frontend to MDE - it will give you a lot of speed. Moreover, it's the only reasonable form of distributing MS Access application to your end users.
for daily work - use MDE file with MS Access frontend. For futher MS Access frontend development use MDB file.
don't use badly written ActiveX components to enhance MS Access frontend capabilities. Better write them yourself or buy the proper ones.
don't believe into the myths that there are a lot of issues with MS Access - this is a great product which can help in may occassions. The problem is a lot of people assume it's a toy or that MS Access is generaly simple. Usually they generate a lot of errors and issues by themselves and their lack of knowledge and experience. To be successfull with MS Access it is important to understand this tool - this is the same rule, like with any other technology outhere.
I can tell you that I'm using quite advanced MS Access fronted to MySQL backend and I'm very satisfied (as a developer which is maintaining this application). My friends, the users are also satisfied as they feel very comfortable with the GUI (frontend), the speed (MySQL), they don't have any issues with records locking or database performance.
Moreover, it's important to read a lot about good practices and other people experiences. I would say that in many cases MS Access is a good solution. I know a lot of dedicated, custom made systems which started as an experiment in form of private MS Access database (MDB file) and then evolved to: splitted MS Access (MDE - frontend, MDB - backend) and finally to: MS Access frontend (MDE) and "serious" database backend (mainly MS SQL Server and MySQL). It's also important that you can always use your MS Access solution as a working prototype - you have ready to use backend in your database (MySQL - let's assume) and you can rewrite frontend to the technology of your choice (web solution? maybe desktop C# application - what you require!).
I hope I helped some of you considering the work with MS Access.
Regards,
Wawrzyn
http://dcserwis.pl
I had an application that worked likewise: an MS Access frontend to a MySQL backend. It was such a huge pain that I ended up writing a Win32 frontend instead. From the top of my head, I encountered the following problems:
Development of the ODBC link seems to have ceased long ago. There are various different versions floating around --- very confusing. The ODBC link doesn't support Unicode/UTF8, and I remember there were other issues with it as well (though some could be overcome by careful configuration).
You probably want to manually tweak your db schema to make it compatible with MS Access. I see you already found out about the needed surrogate keys (i.e., int primary keys) :-)
You should keep in mind that you may need to use pass-through queries to do more sophisticated SQL manipulations of the MySQL database.
Be careful with using lots of VBA, as that tends to corrupt your frontend file. Regularly compressing the database (using main menu, Tools | Database utilities | Compress and restore, or something like that --- I'm using the Dutch version) and making lots of backups is necessary.
Access tends to cause lots of network traffic. Like, really huge lots. I haven't been able to find a solution for that. Using a network monitor is recommended if you want to keep an eye on that!
Access insists on storing booleans as 0/-1. IMHO, 0/+1 makes more sense, and I believe it is the default way of doing things in MySQL as well. Not a huge problem, but if your checkboxes don't work, you should definitely check this.
One possible alternative would be to put the backend (with the data) on a shared drive. I remember this is well-documented, also in the help. You may want to have a look at some general advice on splitting into a frontend and a backend and code that automatically reconnects to the backend on startup; I can also send you some more sample code, or post it here.
Otherwise, you might also want to consider MS SQL. I don't have experience with that, but I presume it works together with MS Access much more nicely!
Gareth Simpson opined:
If it's only two users, then Access
should do just fine if you put the
.mdb on a shared drive.
Er, no. There is no multi-user Access application for which each user should not have a dedicated copy of the front end. That means each user should have an MDB on their workstation. Why? Because the objects in front ends do not share well (not nearly as well as Jet data tables, though there aren't any of those in this scenario using MySQL as the back end).
Gareth Simpson continued:
I believe the recommended max
concurrent users for Access is 5 but
on occasion I've pushed it past this
and never come unstuck.
No, this is completely incorrect. The theoretical limit for users of an MDB is 255. That's not realistic, of course, as once you reach about 20 users you have to program your Access app carefully to work well (though the things you need to do in an Access-to-Jet app are the same kinds of things you'd do to make any server database application efficient, e.g., retrieving the smallest usable data sets).
In this case, since each user should have an individual copy of the front-end MDB, the multi-user limits of Access/Jet are simply not relevant at all.
I know this doesn't answer your question directly, but it might be worth checking out the SQL Server 2005 migration tool for Access. I've never used the tool, but it might be worth using with SQL Server 2005 Express Edition to see if there are the same issues as you had with MySQL
Dont forget to put some type time/date stamp on each record. sometimes ms access will think "another user has changed or deleted the record" and will not allow you to make a change! I found this out the hard way.
In general, it depends :)
I haven't had a lot of problems when the application side has just been updating the data through the forms. You can get warnings/errors when the same row has been updated by more than one user; but Access seems to be constantly updating its live record sets all the time.
Problems can happen if Alice is already working with record 365, and the Bob updates it, and then Alice tries to update it with her changes. As I recall, Alice will get a cryptic error message. It would be easier for the users if you trap these errors and at least give them a friendlier error message.
I've had more problems when I was editing records in the VB code through RecordSets, especially when combined with editing the same data on forms. That's not necessarily a multi user problem; however, you have almost the same situation because you have one user with multiple connections to the same data.
If it's only two users, then Access should do just fine if you put the .mdb on a shared drive.
Have you tried it first rather than just assume it will be a problem.
I believe the recommended max concurrent users for Access is 5 but on occasion I've pushed it past this and never come unstuck.
On the other hand I did once use Access as the front end to MySQL in a single user environment (me). It was a singularly unpleasant experience, I can't imagine it would become nicer with two users.