Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 9 months ago.
Improve this question
I have currently setup a form with various subforms that will update the respective tables in a single database.
However, I was wondering if there is a solution where I can have the form accessible to others outside of Access. In other words, does anyone perhaps have a solution for allowing different people to input their data into the form without directly accessing the database and potentially editing table data?
Not really. You can certainly use the free edition of Access and install that on each desktop if they don't have Access. And as a general rule, right before deployment you should compile your accDB application into an accDE (a compiled version of your application).
So, there are a good number of commercial applications written in Access that uses the above approach. However, YOU the developer then on startup would hide the navigation pane, perhaps provide a custom ribbon, or whatever. In other words, the UI, the forms, and the ability to say run reports all needs some forms and UI to be built by you. (the runtime does not for example provide the navigation pane. So, as long as you build a full working application in which the users really don't know much about Access, and don't care, then you should be ok.
This extra "polish" is of course lots of extra work - but that's the case for any application, including ones built in Access.
So, you can have each desktop install this free runtime edition of Access. They thus don't have to purchase MS-Access, but they will have to install the free Access Runtime. (or you can put together an installer that does the install of the Runtime for you). So, if you are going to view and use PDF's on your computer, then you need some kind of PDF viewer. If you going to use Word on your computer, then you need Word or some software installed for that purpose.
And if you going to deploy FoxPro, or even vb.net programs? Then again, the correct runtimes MUST be installed on each computer for that software to work. And lo and behold, this also applies to MS-Access. In fact, even for compiled VB6 programs, STILL require the VB6 runtime to be installed on each workstation.
The runtime system for MS-Access used to be a paid "add-on" feature. (quite expensive at one time). However, the MS-Access Runtime is now free, and is a free download from Microsoft. However, it does not come with an install wizard for your application. However, a good number of free installers such as Inno can be used. So that installer can do things like create a folder for the application, create a shortcut on your desktop with an icon, etc. So, like any application you install, there are often lots of things you need to do. You can also provide some instructions, but for users to manually have to create a folder, a shortcut on the desktop, etc. is often asking too much of them.
So from the install process, to how great of UI and user-friendly menus and forms you provide to the user? That's up to you, and as noted, that last extra part to make the application friendly often requires a lot of extra work.
As noted, setting up your application to look nice, have all the features built in nice forms, etc. can be a LOT of work. If your applcation say has a nice form for selecting what report to run, prompts for date ranges, etc., and menus and forms to navigate around the application WITHOUT the user requiring knowledge of MS-Access?
Then your application is in good shape, and can thus be distributed to each workstation - even those without a full paid version of MS-Access. However, the runtime of MS-Access is in effect a version of Access, and like installing any office program, it STILL a large install.
And of course this means using a split database. (front end application part, and then back end database ONLY part).
At one time, the Access Runtime was about 30 megs in size. Last time I looked, I think its around 200 megs, I have not looked close at latest 2016 Runtime.
So, at the end of the day, users will require the paid edition of MS-Access, or they can install + use the free Runtime edition of Access and then they can run your application when placed on those workstations. How well your application will work and run as runtime VERY much depends on how great of a job you have done already, and if you have nice prompt forms, etc., and made efforts to hide most of the Access built-in user interface (UI).
However, if most users do not need the whole application, and are to enter JUST some data, and not need to run all the fancy features of your application? Then perhaps for each user, maybe a web-based system for that data input, and then your MS-Access database also shares and runs from the same database. So, you might have a complex manufacturing and scheduling system built in Access. But, you might also want a customer to go on-line and enter just a bit of data, or approve a project or some such. So, they don't need the whole application, but just use of some small bits of the application.
I mean, why have staff phone up a customer to approve some project, then you fire up your application, and on a screen now enter some information to approve or change the status of the project when the customer "on-line" can do that simple task (and save you the time and efforts on the phone or by sending some email to that customer).
So, it really depends on what kind of data entry for those few forms, but often for that kind of work, you would use web-based, but still continue to run your complex desktop software with all the extra features, and reports etc. that only your internal staff require (but, still allowing customers to do some data entry for you, or to inquire or approve projects, etc. on-line).
So, for internal software, Access can be great. But, for just a few data entry forms for lots of people, then MS-Access is not ideal, since they will need to install that software on each of their desktops, and will also need that MS-Access Runtime to be installed.
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 save the ms access file form in the network where is accessible by everyone. Everyone has a link on their desktop to the file in the network. Every time I change the file I have to ensure every one has the ms access file closed.
I really don't want to go looking everywhere to check if the app is closed. I've also set the file to read only, but no luck...
The basic concept for MOST software in the market places is you have two parts to application:
Word documents (data) + the word program executable
Excel document (data) + the word program executable.
So for 20 years in your company, how do you deploy software?
Answer:
You install the program on EACH computer.
So you are talking about a SOFTWARE program that you developed. Just because you use c++, vb.net or Access to CREATE SOFTWARE, then you don't break this rule. There is a difference between a data file a document and COMPUTER PROGRAM.
A COMPUTER program has code, forms and user interface. So if your computer support people don't know the difference between a document and a computer program then this would be the source of your problems.
As a result, you don't allow multiple people into the one program. I mean, if one person in your building has trouble with word does everyone go home?
And while you work on the NEXT great version of your software, users should not care.
So, this means:
Like most of your software, you deploy it to each user's workstation. This will allow you to work on the next great version of your software.
When you are done your changes and added new code and new features you then:
Compile the program into an executable (in Access, this is an mde, or now an accDE. You then deploy this to each users workstation.
The above approach thus allows you to work on the NEXT GREAT version of your software. You can add to your software some update code, or even just adopt a logon script that copies down the next great version of this software to each user's desktop.
The result is:
You don't care if users are in their current version of their software, since you are working on that copy which is not locked.
So, you should be distribution a compiled version of your software, and like most of your software you REALLY WANT to distribute that software to each user's workstation.
Last but not least:
Programs like Word, or Excel have what is called re-entrant code. So if you are working in a terminal server environment, then those office programs tolerate multiple users on that server, but your program created with Access DOES NOT. So even in this case, each logged on user is to receive their OWN SEPARATE copy of the COMPILED program you created.
So how c++ works, vb.net, VB6 or in this case Access works is the SAME for most programs:
You distribute that program to EACH user's desktop, and thus the issue of you working on the next great version is a non-issue. You simply have to setup and adopt a means to check for a new version. That means you distribute a program update, not a single form update. Even in the case of changing come code, or modify a report, that will cause you to like MOST software to have to issue a new version.
So, if you issue a new version of your software you not have the problem you outline. Those users don't have to get out of their current version since you are working on a copy of the program.
You thus need to adopt some system and code that will allow you to roll out that update to each user.
I explain in details not only should you run a split database with the data and tables separate (as you have), but ALSO why you distribute a compiled edition and ALSO why EACH desktop should receive a copy of this new program here:
http://www.kallal.ca/Articles/split/index.htm
So the ONLY basic concept you need to grasp here is that in the computer and software industry we have a concept of a computer program. Once you are able to grasp that you are creating a computer program, then you can NOW grasp the concept that such programs AFTER you create such a program or AFTER you modify or create a new version of that program, you THEN distribute that NEW program to your user base. This is quite much how all software works, and Access is no different in this regards.
You don't try to include one form into the production software, but add the new form, modify code and then COMPILE the software into an executable. In fact, using a compiled Access application is strongly recommend since un-handled errors NEVER re-set global variables and as a result your software becomes far more reliable and that even includes code without error handling since local and global vars are never re-set.
One solution would be to maintain a copy of all forms, reports, modules, queries, etc (front-end code) in a separate database from the tables. You can then link the tables to a 2nd database (back-end) in a shared network Access DB. The front-end database would be deployed to each workstation, while the back-end database is shared. Obviously, this introduces the need to update each workstation, but it means that when you need to roll out new front-end logic, you don't have to go around kicking everybody out at once.
Otherwise, sadly, you need to acquire an exclusive lock on the database, and the only way to do that, is to be the only one with it open.
With the help of a script, you could automate pulling the latest "client". You could just ask all users to exit the app and double-click a batch file which copies the front-end from some network location.
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.
Would you recommend working with multiple programmers on an MS Access application?
One of our MS Access application has grown to the point where the number of changes (bug fixes) and new features can no longer be handled by one programmer in the requested time frame.
We are trying to introduce version control using the undocumented SaveAsText and LoadFromText procedures in VBA to make collaboration on this application possible. Unfortunately we have already run into problems loading modified forms and reports back into Access as a checksum is stored in every form text file.
Before putting time into building an import/export application to compile text files into an Access database, we would like to hear your recommendations.
I think you should avoid this path at all cost, and try and persuade management into redevelopment.
It's a bitter pill to swallow, but this is going to need to be redeveloped sooner or later, and you are just saving them time and money.
We were using Microsoft's own version control add-in for MS Access 2000/2002/2003 for about 5 years now, and I can't remember a single serious problem. Usability of this add-in barely deserves a "B", but it must be much, much more convenient than fiddling with any ad-hoc method involving manual or semi-manual exporting/importing of Access forms, modules, etc.
We were using VSS as a version control system all the time. No problems whatsoever. However, if you have some good reasons to avoid VSS, you may have some options:
The version control add-in that we were using does not require VSS. Theoretically it can be used with any version control system that implements Microsoft Source Code Control Interface (MSCCI). For example, when we had to let somebody work on this project remotely, we used SourceOffsite by SourceGear. Access version control add-in worked with this third-party product fairly well (not without some quirks, but well enough). So, if your favorite version control system complies with MSCCI, you could try to use it.
Now that Microsoft has this Team Foundation thingy, apparently there are other options to be used to integrate MS Access with version control. We did not explore this path, though. This article may be a good start for exploring it.
Hope this would be of some help. :-)
P.S. I am not a big fan of MS Access. In fact, I rather hate it as a platform for a user front-end. If I had a choice, I would run away from it yesterday. :-) However, I must admit that existence of this version control add-in is one of the few things that makes maintenance of our old Access+SQLServer project more or less tolerable. :-))
In addition to what I already said here, I should add that the whole system works very well. The comparison process takes less than 30 minutes a week, for a team of 3 programmers. So let's describe it a little bit.
We have basically 2 versions of our Access program:
The "Developer's version", with all the stuff in it.
We each begin to work with an identical version of our developer's edition. As each one modifies or add parts of the code, we have to run some comparison routine on a regular basis. To do so, we have an object-export routine to a common "comparison" folder. An object (module for example) is exported as a text file (saveAsText command, do not work with tables, see infra), it will be compared to the existing equivalent text files in the folder. If files are identical, there is no file exported. If files are different, the new module is exported with the developer's name as an addition to the file name (if modQueries.txt exists, then modQueries_philippe.txt is created...). Of course if there is no equivalent .txt file in the folder, it will be created at first export.
At the end of the period, we would get in our folder the following files
modQueries.txt, being the first "original", last common version of the module
modQueries_Philippe.txt, with Philippe's modifications
modQueries_Denise.txt, with Denise's modifications
As the module was not modified by other developers, their export did not lead to the creation of a specific modQueries_developersName.txt file
If for any reasons Denise exported many times her module, only the last version is in the comparison folder.
We can then compare (with a "text file" comparer) the different versions and create the "updated" version of the module. We have a screen giving us the number of objects in the comparison folder, number of version for each object, and it is even possible to open the file comparer directly from the developer's interface (We use "File Compare Tool" which has a command-line mode and can then be started directly from Access).
The forms compare issue is quite special, as one of our rules is to have no specific code in our forms (please see here for more details). Forms are then only for display, so usually we do not even compare them. We just make sure that each one of them is updated by only one person (which is quite logical).
The table compare issue (we have local tables) can be only made between mdb files. As we export one text file per module, we also export one mdb file per table. We have a small routine allowing us to identify table differences at the structure level or at the record level.
After each comparison procedure, a subroutine will use all the objects available ini the comparison folder and create a whole new clean mdb file from scratch. This is the new developer's version. Every developer can then copy it on his computer and continue his work.
Developer's versions do not have numbers, but contains last client version number.
The client version, with limited stuff, automatically distributed to users
Each developer has the possibility to build a "client" mdb for final users. This mdb is created from scratch, in a way quite similar to our developer's version, but not all objects are exported. Some specific switches are turned off (special keys, access to code, etc). This mdb holds a version number as a property. The version number is used to build the name of the mdb file.
At production time, this mdb file is zipped and placed in a specific "distribution" folder. Each time a user starts the app, it will automatically check this folder to see if a new version is available. If yes, the client mdb file is updated from the distribution folder, and the app is restarted.
This distribution folder is replicated at night time with our overseas agencies. Users abroad will then be able to install the new version on the following day.
Following the direction provided by Yarik we settled on continuing developing in Access using the Access Add-in Source Code Control, the SVN SCC API Plugin by PushOk Software and Subversion. This stack provides us with seamless Access integration, full-backup and restore and an open version control system.
We had to install a hotfix to Access 2003 and make sure the default database file type matched our database file type to make it work.
We will continue to update this answer with our findings.
Have look at this thread:
How do you use version control with Access development?
Sounds like a terribly painful way to do team development. If you have any options for porting to another environment like VS2008 that would be my recommendation.
There is no easy way to work on Access as a team and even version control might be a bit tricky.
I have been asked by a friend to help him assess a number of quotes for porting a desktop application based on MS access and VBA to a web based app. The application seems to have a relatively large amount of business logic coded into the VBA.
My question is very specific - are there any good tools or resources out there which could assist the porting from access, rather than doing a complete re-write?
The end technology used for the web app does not matter hugely, but would ideally be as mainstream as possible.
You may explore the possibilities offered by Sharepoint. It may help you get the data accessible online but how well will that work depends also on how much VBA code was used in the Access application.
There are some tools around that pretend they can convert MS Access to PHP/ASP websites like DB Forms, but I haven't tried them and they usually only convert the visible part of the app and not the queries and VBA.
They can be helpful to get started though.
Random thoughts
The VBA tends to be the biggest issue.
Moving to ASP.Net will take time and for that you are faced with difficult choices:
transfer all code to the ASP.NET to just get it working
rethink the structure and do a proper ASP.Net implementation from scratch.
I'd prefer the first one: just try has hard as possible to get results fast.
Use SSMA to move the data to SQL Server (unless you want to keep Access as the backend).
Make the forms look the same as on your existing application (or at least have the same function), port the VBA to VB.Net (or C# if you feel like it) form by form, module by module and test that they work as you go along.
Don't try to refactor or make things better at this stage, the point is to 'slap' the old code on the new 'system' and make it bark as it used to, not better, not worse.
Only then can you start refactoring and improving using the new tools at your disposal.
I'm saying all this assuming that there was nothing terribly wrong with the old app and that it just needed to be ported for online consumption.
If the old app was defective and wasn't fulfilling its role, then more emphasis should be placed on re-thinking which parts should be translated and which one should be reworked.
At any rate, you need to have a detailed action plan and a review of the current code and functionalities and try to limit as much as possible your expectations for the first version of the new system: avoid letting everyone input their wishes or your project will become horrendously difficult.
Concentrate on the minimum needed to achieve a certain level of functionality that will satisfy your users, then build on that.
There may be some tools to some of the basic stuff, like to upsize to a different database or maybe the look and text boxes of the forms, but converting what sounds like a lot of VBA code, not so sure.
Is this an intranet/local network type of web app or are you putting it out on the internet? Security will become a major difference between this and your Access app.
Make sure they understand Access/VBA so you can maintain the business logic that has been over the life of the Access app.
Convince your friend to stop/slow any development on the Access app to prevent the company from aiming at a moving target. This may not be realistic, but really needs to be considered.
Is there a reason why hosting the app on Windows Terminal Server would not suffice? This means zero changes to the app, no reprogramming cost and no danger of losing crucial business logic. If you use the Citrix extensions, you can run it in a web browser (though I guess that only works with IE -- I've never used them). But the RDP client comes in versions for Mac and Linux as well as Windows, so you can basically support anybody as long as they install the RDP client for their OS.
Yes, it's more installation on the client end, but it's a helluva lot cheaper and easier on the development and avoids the problem of losing important things coded into the Access app.
Of course, supporting large user populations on WTS/Citrix can get expensive and if the Access app is in need of re-engineering, anyway, it can change the balance. But it's something that you should consider. It's really easy to set up WTS, in fact, and provisioning a server for it basically a matter of adding RAM and Internet bandwidth (though RDP is really efficient to begin with).
One key mistake many people make when trying to run an Access app on WTS:
YOU MUST SPLIT THE DATABASE (front with forms/reports/etc., back end with data tables only), and each user must have their own copy of the front end (stored in user profile on the WTS, or in a folder on your WTS server's data partition with appropriate permissions assigned to the user groups authorized to use the app). Tony Toews's front-end updater is very useful in this context, and explicitly engineered to work in a Terminal Server environment.