CranberryFog
asked on
Web I/O for an Access application
I have developed an Access application used by a client on a single PC in a college environment to run game scenarios. There is a single Access form run by the game administrator to enter player input, less than 20 elements per form, 1 form per team, 5 or more teams per round, up to10 rounds per game - Lots of games. lots of typing. At the end of each round, results are printed and distributed. Lots of paper, lots of time wasted, and the number of games run is growing.
I need to find or develop a dual purpose Web alternative whereby (1) input, properly authenticated, is collected in an on-line database that I can retrieve with the administrating Access app that will remain on a PC (for now), and (2) output in the form of viewable/printable PDFs are accessible to the players.
Should I bite the bullet and start adding PHP programming to my skill set (I do not plan on taking other web dev accounts), sub out the form development, or does anyone have positive experience with hosted services out there like Caspio that might make this workable?
Thanks for any suggestions you might have.
I need to find or develop a dual purpose Web alternative whereby (1) input, properly authenticated, is collected in an on-line database that I can retrieve with the administrating Access app that will remain on a PC (for now), and (2) output in the form of viewable/printable PDFs are accessible to the players.
Should I bite the bullet and start adding PHP programming to my skill set (I do not plan on taking other web dev accounts), sub out the form development, or does anyone have positive experience with hosted services out there like Caspio that might make this workable?
Thanks for any suggestions you might have.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Marc,
<<Thanks very much. After reviewing the eqldata site/faqs, I am going to give it a try.>>
Would love to hear some feedback on how that goes. They've been around for quite a few years now, but we haven't run into anyone here on EE that's used them yet.
Jim.
<<Thanks very much. After reviewing the eqldata site/faqs, I am going to give it a try.>>
Would love to hear some feedback on how that goes. They've been around for quite a few years now, but we haven't run into anyone here on EE that's used them yet.
Jim.
ASKER
Glad to. I have talked to my client and we are going to give it a try.
What is the best way to post feedback; as a comment to this question or some other mechanism?
What is the best way to post feedback; as a comment to this question or some other mechanism?
Post it here please if you would. I'll point all the other Expert's in the Zone to this thread.
As I've said, they have been around for a number of years now and we've been pointing them out to people, but we haven't heard of anything positive or negative about them, which is a bit strange. So keep your eyes open and make sure it works for you.
Their demo seems good and if they can do what they say, it's a very viable alternative to getting an Access DB "on the web". And a attractive one at that, because you run the same DB for your local users vs the web ones. No other option even comes close to that in terms of ease.
Some go the route of setting up a terminal services server, then throw Citrix on top of that and you end up with Access through a web browser. While that's a plug and play solution and not expensive per say for a small number of users, if you get into hundreds of users, it gets expensive.
Outside of that, you can use Access 2010 with SharePoint and put an Access DB on the web. Issue with that is cost (you need an enterprise license for SharePoint) and you have very limited functionaility (ie. NO VBA code allowed) as you must use a "web" enabled database format.
For most apps, that means a re-write anyway and if your going to do that, then why bother living with the restrictions? You might as well just do a regular web site and ditch Access.
But of course a total re-write depending on the app may not be cheap either.
Really looking forward to hearing some first hand experience on that service.
Jim.
ASKER
Yes, we had already ruled out an "MS Solution" - this app has intense VBA - as well as terminal server-like alternatives as we want flexibility and OS freedom that only a web option gives us. The idea that we might do this with little or no re-writes is unexpected and way, way beyond attractive.
I already have the app up on EqlData's server and am trying the plug-in. I keep waiting for the other shoe to fall, but so far so good.
More to follow...
I already have the app up on EqlData's server and am trying the plug-in. I keep waiting for the other shoe to fall, but so far so good.
More to follow...
ASKER
The good news so far:
Signed up, read the quick start info, uploaded an app, made two small recommended adjustments (Use random rather than incremental numbering for Autonumber field IDS), and was running the app in Firefox, all in about 15 minutes total.
Access runs in the plugin, and only slightly less snappy than a local network connection. Runtime Access is calling the shots, so you must control everything with forms - no database window, object browsing, etc. Most of our underlying VBA operates as expected.
Limitations:
It is running on their server after all, so reference to local externals (e.g. OPEN x FOR INPUT) fails, printers are not immediately available, and error reporting will need to be tweaked to accommodate the difference.
Elephant in the Room:
The product uses Adobe Flash to get to your browser. If you are looking to the web to free yourself of OS dependency, especially for mobile devices like tablets, iPads are already inaccessible and, after yesterday's Adobe announcement (see http://www.reuters.com/article/2011/11/10/us-adobe-apple-idUSTRE7A84NO20111110 ), Android won't be far behind. I have left the dev crew an inquiry to see if they plan to migrate, but no response yet.
However, for most of what I do in Access, this is a fast, clean solution.
MTF...
Signed up, read the quick start info, uploaded an app, made two small recommended adjustments (Use random rather than incremental numbering for Autonumber field IDS), and was running the app in Firefox, all in about 15 minutes total.
Access runs in the plugin, and only slightly less snappy than a local network connection. Runtime Access is calling the shots, so you must control everything with forms - no database window, object browsing, etc. Most of our underlying VBA operates as expected.
Limitations:
It is running on their server after all, so reference to local externals (e.g. OPEN x FOR INPUT) fails, printers are not immediately available, and error reporting will need to be tweaked to accommodate the difference.
Elephant in the Room:
The product uses Adobe Flash to get to your browser. If you are looking to the web to free yourself of OS dependency, especially for mobile devices like tablets, iPads are already inaccessible and, after yesterday's Adobe announcement (see http://www.reuters.com/article/2011/11/10/us-adobe-apple-idUSTRE7A84NO20111110 ), Android won't be far behind. I have left the dev crew an inquiry to see if they plan to migrate, but no response yet.
However, for most of what I do in Access, this is a fast, clean solution.
MTF...
Thanks a bunch for posting that!
Jim.
Jim.
ASKER
Jim
One more follow-up: This is an amazing solution.
So far, EQL-Data has proven to be everything we'd hoped, and we have already tested at least 95% of our intended use. Flexibility, support, bug-free environment, reliable server, fair pricing, and no need for out-of-Access programming to get Web I/O make it a great fit. Their tech folks are responsive, and we have learned to tweak the underlying EQL-Data tables to get more: push updates from our development station up to the web, and then pull them down to the client, all with push button ease for the user (short, simple VBA). We can re-point developing MDBs to working vs live replicas on the server. And we have independent control of Access components (e.g. tables vs forms) in the synchronization process.
The fact that it is running on a server requires some re-thinking in terms of how you reach a local box, but we have solved all of those issues. And they have a default printer handler that slips you a PDF of any intended print to do what you will locally.
Regarding the Adobe Flash issue above, the current version still requires it, but as the need arises, they claim a migration to HTML5 or some other supported solution would be moved up the priority list.
I know it is a lot of pros, but I just don't have any cons. Highly recommended to anyone looking to add Web forms without leaving Access. Once again, thank you so much, Jim, for this solution.
Marc
One more follow-up: This is an amazing solution.
So far, EQL-Data has proven to be everything we'd hoped, and we have already tested at least 95% of our intended use. Flexibility, support, bug-free environment, reliable server, fair pricing, and no need for out-of-Access programming to get Web I/O make it a great fit. Their tech folks are responsive, and we have learned to tweak the underlying EQL-Data tables to get more: push updates from our development station up to the web, and then pull them down to the client, all with push button ease for the user (short, simple VBA). We can re-point developing MDBs to working vs live replicas on the server. And we have independent control of Access components (e.g. tables vs forms) in the synchronization process.
The fact that it is running on a server requires some re-thinking in terms of how you reach a local box, but we have solved all of those issues. And they have a default printer handler that slips you a PDF of any intended print to do what you will locally.
Regarding the Adobe Flash issue above, the current version still requires it, but as the need arises, they claim a migration to HTML5 or some other supported solution would be moved up the priority list.
I know it is a lot of pros, but I just don't have any cons. Highly recommended to anyone looking to add Web forms without leaving Access. Once again, thank you so much, Jim, for this solution.
Marc
Glad to hear it's working well for you!
Jim.
Jim.
Pretty cool. Goodbye SharePoint ?
mx
mx
ASKER
For us, Sharepoint never was a contender.
We use Access as database handler for conversions of older code (FORTRAN, BASIC) applications - tons of VBA, mix of Access versions, and a desire for serious OS freedom. So we develop in a mix of environments. The client currently using this solution runs the master application in Office 2003 on an XP laptop, which syncs to EQL-Data run-time replicas that the users pull up in any browser supporting Flash 10 in Windows, Macs, Linux, etc. Even brought it up on an Android smartphone browser.
Best all-Access solution for us.
We use Access as database handler for conversions of older code (FORTRAN, BASIC) applications - tons of VBA, mix of Access versions, and a desire for serious OS freedom. So we develop in a mix of environments. The client currently using this solution runs the master application in Office 2003 on an XP laptop, which syncs to EQL-Data run-time replicas that the users pull up in any browser supporting Flash 10 in Windows, Macs, Linux, etc. Even brought it up on an Android smartphone browser.
Best all-Access solution for us.
Damn that's cool. Hate to date myself, but I started with Fortran 2!
And guess what is still with us today:
For x = 1 to 10
' oh yeah
Next x
Watch Microsoft buy up eqlData ... :-)
mx
And guess what is still with us today:
For x = 1 to 10
' oh yeah
Next x
Watch Microsoft buy up eqlData ... :-)
mx
One drawback to eqldata is they don't support Access 2010. The tech I spoke with was unsure when they'd have support for 2010.
Yeah, and I asked them that same question several months ago ... so, looks like not much progress :-(
I supposed it's just a matter of time.
mx
I supposed it's just a matter of time.
mx
ASKER
Anyone uses CC"s form builder?
Other's out there worth looking at?
Thanks again, Jim.
Marc