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.
Related
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.
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.
A customer of mine asked me a better and faster solution to update it's real estate web site as he and his employees don't want to connect to the web site and update one by one the ads as they don't want to loose time waiting the normal latency of the internet.
I firstly solved the issue by building a PHP script that imported an Excel file into the web site's MySQL database and it worked greatly. But the problem were pictures that have still to be uploaded separately. I then wrote a PHP script that uploaded the pictures using ajax and drag&drop so the user could select multiple pictures and upload them at once. And this worked too, but the customer is still not completely satisfied as he says this solution is quite 'patched'.
I then thought about a desktop application - a kind of local database (could be SQLite) - that the user keeps updated locally and only at the end of the day the app connects to the remote server and updates the db and uploads the pictures.
My question is: what EASY desktop high level programming language I could use to do the job? Do you know any RAD (visual IDE) programming language able to connect to a remote mySQL server and upload data via a simple custom GUI?
I tried RealBasic and PureBasic but I did not work it out. I thought about building the app in PHP and then convert it to EXE but I did not tried yet.
Please don't suggest me Java, C or Delphy as I'm looking for something very easy.
Thank you
Have you considered a client side javascript/html app that syncs with the server, since you're already familiar with the platform? If one browser better supports what you want to do (Firefox has some extension perhaps vs Chrome, or whatever), than mandate that to run this app (rather than worrying about being portable across browsers).
All of the browsers can have client side storage now, and you can just do things locally, and finally push them to the server "all at once".
If your client is using a Windows platform, you could use IronPython (.NET), VB.NET, or C#. These all allow you to create windows/forms visually in Visual Studio. If you're not already familiar with the .NET platform I'm not sure how 'easy' this will be, but I think that's going to be true for most other platforms as well.
That being said, it sounds like your existing solution is probably the best idea - perhaps if you can make your solution feel less like a "patch" they will be satisfied.
No reason you can't use Purebasic if that's what you're comfortable with. There are HTTP file upload examples on the PB forums.
I've used Purebasic for years but I'd recommend spending the time to get to know C#/.NET - it's a world of difference and once you learn it stuff like this is pretty easy.
Some background:
We provide a complex system consisting of a large database and several programs - most written in C#, however some legacy applications are still running on MFC.
Most of the stuff we provide runs on a single server (runs SQL server and SQL Management studio 2005), however several applications can run on a number of client's computers. Updating this is a real pain, since after we update the database the outdated software is likely to break due to database changes. Updating the server software manually is one thing, however making sure all the client software works too is practically impossible, and will only get worse with time.
I am to write an updating service, which will be able to update the whole product - update the database, reinstall services and applications. (However only the programs / files /tables / etc that are actually modified should be updated. Downloading the whole product each time there is a update available is not an option. Also, some computers may only have a subset of avaliable programs installed)
First of all is there a already a good way of doing this? If there is something similar to ClickOnce that would also be able to update databases already out there I'd much rather use that.
If not, what are the best practices when it comes to updating? All and any material will be greatly appreciated.
I will need some updates to be installed on the server ASAP after the updates have been submitted, without any user input. That includes a windows service (that is running at all times) and any database changes. After these changes have been made, I will have to prevent any software that is not up to date from either accessing the parts that have been changed, or from running at all.
Any advice will be greatly appreciated - If I do have to write a system like that, I'd like to do it right.
Best practice would be to package the app up in an MSI and use Group Policy to push the updates out to each client.
If that's not possible then you need some way of informing the client app that it is out-of-date (simple check against a server holding the current version number would probably suffice) and refuse to work until an update patch is downloaded and installed - you could even launch this process from inside the app itself.
This answer may help you, I haven't personally used Wix but this seems to be along the lines of what you're looking for. Make sure to check out Lesson 4 in the linked tutorial, as this provides the details you would require.
I'm not sure where you would find best practices when it comes to updating, but in my personal opinion you shouldn't ever force a user to update unless it breaks the underlying application (like yours does). I would be very interested to hear if someone has a link to a list of best practices on this topic.
Edit
I was interested in possible best practices for updating so I started another question thread here. The general consensus in the answers is "Ask the user/client", but there may be some other details in the answers which may help you, I'm afraid I can't find any actual hard rules on the subject anywhere (which I was expecting).
I'm working on an eCommerce website for a small merchant. This merchant uses Opera (which is based on Visual FoxPro) to manage his in-store inventory, and would like the online store inventory to reflect the in-store inventory.
I'm guessing that my first step is to set up a way to regularly transfer the information from the VFP database to a MySQL database on the website's server. Is there an established process for this? Am I even approaching this problem from the right angle? I've heard a lot about ODBC, but am unsure as to how to implement it or if it's what I'm looking for in this situation.
If it wasn't obvious by this point, I'm in over my head here, and would appreciate any and all advice you may have, including links to articles or tutorials that can help improve my general understanding of all the moving parts here.
Thanks much.
Co-worker developed synchronization process between VFP and MSSQL2008. WCF service which took input directly from VFP.
On other project - as far as i remember, when we tried ODBC .NET data adapter, it had problems with encodings and foreign languages. That's why we used COM+, serialization for communication with .NET.
But it seems to me you are using PHP (eCommerce=>Drupal=>PHP) so you are in completely different situation.
In your case, i would start with checking out if Opera (i guess it's this Opera) provides built-in export and eCommerce provides built-in import. Mostly because it might be tedious work to sync data manually from 2 apps coded by someone else. Then i would research if i/o can be joined and automated (something like scheduled task on win environment). Unfortunately, can't help much more because i'm unfamiliar with those tools, products and technologies.
Anyway - it seems to me like quite hard and dirty task and i wish you good luck. :)
Depend on what is that you are using to implement the website.. in general it is pretty easy with ODBC (In Java , I did it using the jdbc-odbc bridge)