Cross platform support?

[YouMust]

Howdy guys,

I've been asked to make our access application available to production staff.
With the intention of adding build notes and logging build times etc.

I'm trying to think of the best way to present this information to the operators.
Ideally a tablet but from what I've read so far (not finished yet) this is not going to happen? I can't find a native access app for android and I'm unsure of the privately made apps unless I get a recommendation from here.

I've read through some FAQ's
https://access-programmers.co.uk/forums/showthread.php?t=241257
which states access is only for windows PC. however, I've noticed that the MD has a MacBook and he's got access running on it !

The other option would be a web app? but from reading about that it sounds like I'll have to rebuild the entire app other than the database tables.

I will continue to read about this, just thought some guy on here will helpfully say 'oh i tried this a year ago and i found X app to work really well

well i live in hope

thanks for your time

 

[Minty]

Your MD is probably running Windows or VM Fusion on the Mac.

A web based interface is really the only way to go, unless you can build a remote desktop version of your database that would run on a tablet.

If you use SQL or MySql as a backend you can create a web based portal to your data that can be as powerful as your web skills allow!

 

[YouMust]

hey thanks Minty,

that's a shame as access is so extensively used with everything here, my predecessor started the business with access and has grown it over the years, changing everything over to web pages from forms would represent months of work.

thanks again though, I do appreciate it as it saves me time trying to figure something out that's impossible to do.

 

[Minty]

You may find alternative workarounds, depending on what you are trying to achieve with the tablet devices?

 

[YouMust]

I can be pragmatic about it and say they dont need any of the current forms on their tablets,
all they'll need to do is select a product and then open the build instructions, which could be handled with simple .html tbh. Can I read and write to/from access 2013 database(is it ACE) using PHP or something ?
https://msdn.microsoft.com/en-us/library/445z2s49(v=vs.100).aspx

I really wanted to avoid having to learn another language, as I'm an electric engineer, not a web developer! we are a very small company just 18 people

but if needs must

 

[CJ_London]

There are win10 tablets out there which will run office/access, tho' many come with a detachable keyboard. But if users already have android etc then this is probably not an option.

There are other considerations - tablets by definition are intended to be used wirelessly, which is not a good mix with Access - So better to move your back end to SQL server/express or maybe MySQL which provides better security in the event of disconnection. If going this route, you may also want to consider using Azure as a web hosted sql server.

Tablets by definition have relatively small screens compared to PC and are controlled by a finger or stylus rather than mouse - so text and controls need to be larger to allow for the larger footprint, whilst forms generally need to be smaller and typically designed to scroll in one direction only for ease of use.

 

[YouMust]

Oh thats great news CJ,

No one has a tablet yet, this is just a little idea/project to help streamline product build times, we currently use paper but when things get updated electronically, productions paper build notes often get forgotten resulting in incorrect builds.

the tablets, for now, will only pull info from access for the build notes and will not be writing to the database so the wifi issues wouldn't be such an issue?

but in any case, if I was to learn and make a html/PHP page I can just use SQL statements to inject or pull data from the .accdb backend tables? and so no need to upsize to MySQL?
The pages/database will be used locally and so external hosts will not be needed.

 

[CJ_London]

if users will not be adding/changing data then you should be able to open the backend readonly which reduces risk of corruption - but if they need to log in and as part of that process 'register' they are connected, they will need write rights as well.

And you can do other things like ensuring the form allow edits/additions/deletions are set to false and instead of populating a form recordsource with say

"SELECT * FROM myTable"

you would use in the form open event

set me.recordset=currentdb.openrecordset("SELECT * FROM myTable",dbopensnapshot)

If you haven't bought the tablets yet, there is no need to buy access/office. Provide them with access runtime which is free, preferable with a .accde front end.

You can connect to access from a web page, method of connection is pretty much the same as for any backend. But consider the long term - are the tablet users going to be entering data in the future? if so, then upgrade the backend now.

No need to mention the tablets will need to have a good wifi connection wherever they are being used - if not this will need to be addressed as well.

Strongly recommend trial it first with a single tablet - make sure users can see the build instructions clearly, they are not going to have glue on their hands when scrolling etc - i.e. that viewing instructions via a tablet is doable. You may find you actually need to attach a screen, in which case a cheap PC would be a better option.

 

[YouMust]

form open event

set me.recordset=currentdb.openrecordset("SELECT * FROM myTable",dbopensnapshot)

If you haven't bought the tablets yet, there is no need to buy access/office. Provide them with access runtime which is free, preferable with a .accde front end.

please excuse my naivety, how does one open an access front end without access installed?

every pc in the company has access purchased in order to use it, or at least thats how I've inherited it. I'm still very new there's so much information it's a little overwhelming.

I really appreciate your advice/s

 

[Frothingslosh]

Microsoft offers free runtimes on their website that will allow you to run Access databases and executables. You can't design using them, but it at least makes it so you only need full copies for the developers.

 

[YouMust]

wait, so your telling me that my predecessor purchased £2500 pounds worth of MS access for every PC for no reason!

you just cant make that stuff up!

 

[The_Doc_Man]

Might not have been for NO reason; it depends on what else might happen. Most of the time we see deployed Access Runtime stuff working fine. There is just that small percentage that for some reason is doing something oddball that doesn't work quite as well. Search the forum for "Access Runtime" for a review of issues that people have had - but there weren't that many as I recall.

 

[CJ_London]

but there weren't that many as I recall.

main issues are that runtime does not provide a ribbon, a navigation window or short cut menus (the ones that you get when you right click on a control, form, whatever). But you can write your own if required which takes a bit more work.

All you need to make sure is that a form opens initially (which you can select through File>Options>Current database) or you can use an autoexec macro to open the form. And then that all other forms and reports are opened from this or another form. That takes away the need for a navigation form. 99% of users will not require the use of the ribbon - sorting, filtering and other operations can easily be done through forms if required and many do not use the shortcut menus (as much because they don't know they are there in the first place)

If you want to see what your existing db looks like when running in runtime, make a copy (to be safe) and rename as .accdr rather than .accdb/e

Main thing to be sure of is that everyone is running the same 'bit' of access - either 32bit (preferred) or 64bit. Just be aware that 64bit access will not run on a 32bit windows device. There is no benefit in running 64bit at the moment.

 

[The_Doc_Man]

CJ

There is no benefit in running 64bit at the moment.

I thought that SharePoint was one of the very rare cases in point that could benefit from using 64-bit Access. Is that not so?

 

[CJ_London]

@Doc, I wasn't aware of that being the case, but I do find the documentation unclear in respect of Access - in this link

https://support.office.com/en-us/ar...f-Office-2dee7807-8f95-4d0c-b5fe-6c6f49b8d261

it says

You're using SharePoint Server 2010 and you need the Edit in Datasheet view. You can continue to use the Edit in Datasheet view functionality in SharePoint Server 2010 with 32-bit Office.

which implies you can't in 64bit, which is a bit limiting and implies that at least some of the sharepoint dll's (whatever) are still 32bit.

Similar statement towards the bottom of this link

https://technet.microsoft.com/en-us/library/ee681792.aspx

And the MS recommendation is still to use 32bit access.

My understanding is the main benefit of 64bit is being able to work with larger datasets in memory. Which is fine for Excel which loads the whole file into memory to be shared with nobody else, but with Access (or any other db front end), the performance is more related to loading data across a network. So excel may take a few minutes to load a very large file, and then it flies, but db's need to work with data in the database, updating as soon as possible to provide the latest view to other users. And with Excel of course, you can only have one user at a time - all others are read only.

So my assumption (and I may be wrong) is that sharepoint, being on a remote server will be fine for excel where you can go and make a cup of coffee while it downloads the data, but no better for access be it 32bit or 64bit.

Would be interested to see an article which demonstrates how sharepoint is better with 64bit access rather than 32bit, it may change my view

 

[The_Doc_Man]

Before I retired, none of us used SharePoint for anything because our security guys had not vetted it. But then, with the craziness associated with the redoubled emphasis on cyber security, the security guys were hiring and couldn't find enough qualified people for all of the requirements that it entailed.

Qualification escalation is one reason why I finally left, though it contributed more to the specific date of retirement and less to the fact of retirement. But I digress. I'll admit that the articles I saw on Access and Sharepoint were ambiguous, too, and I didn't have an immediate need for it anyway, so I let it slide.