Access on a Microsoft tablet

[Jason Dundas]

I'm wondering if anyone has tryed to run access on the windows tablets? Does it work or is it too awkward/slow?

 

[CJ_London]

make sure the tablet has windows 8/8.1 - earlier windows had a cut down version which would not run office applications

re speed, depends on network speed and how well the db is designed to minimise data traffic same as any other wireless device. If running a standalone version just on the tablet, my experience is it is OK but not as good as other devices with more memory/processor power. Wouldn't dream of using it for developing or anything which required significant data manipulation.

 

[GBalcom]

CJ,
Don't mean to hijack the thread, but I have the same questions....In my case, I would be using Access 2010 runtime on the tablets, to run a "read only" app I would create to read information off our ERP system database. We are a manufacturing company, and this would be used on our shop floor.

I'm fine with getting windows 8 or 8.1 on the tablets, but with 6 or 7 of these connected wirelessly...am I asking for trouble? Other than pass through queries, what else can I do to minimize network traffic?

Thanks in Advance!!

 

[jdraw]

See this for others' thoughts

 

[spikepl]

Define "tablet".

I have MS Surface Pro 2 with Win 8.1, 128 GB disk and 4 GB RAM and this great piece of kit is faster than my Lenovo laptop with 8 RAM and I develop on both machines.

Note jdraw's link: reading is different from writing

 

[spikepl]

@balcom

Google. Plenty of threads with advice for speeding up Access

 

[GBalcom]

Thanks Spike,

Tablet...I haven't purchased any for this purpose yet. The only thing I know of at this point is I'll need windows 8 or 8.1, with bullet proof cases, and as I'm buying 7 of them, I'll need to keep the price reasonable, say under $500. Any Recommendations?

 

[jdraw]

The only comment I can make is from participation in other areas. The underlying theme was--if you are using wireless network then make sure you move from Access backend to SQL Server (Express free) or some other server based database(MySQL, Oracle...).
One very experienced poster reported continuous loss of records (network outages/issues/hiccups were determined to be the base problem) with Access backend on server. Loss of 100's of records from time to time. Problem was resolved by moving to SQL Server Express as backend.

You may find other issues, but this was reported and debated by several very experienced Access developers.

Good luck.

 

[spikepl]

@jdraw

How recent was that experience? By now the 802.11 n protocol can be faster than the 100 Mb/s that used to rule the networks, so do those considerations still apply?

 

[GBalcom]

Thanks guys! Forgot to mention that the back end is SQL and I'll only be reading records, so I'm hoping I'll be ok

 

[spikepl]

Just remember that new features tend to escalate very rapidly. "Why can't it yada yada ..."

Once you get something going, many will immediately see the potential for many other enhancemnts. Which may be a good thing, so infractucture changes need, ideally, be at least two steps ahead.

 

[jdraw]

spikepl,

This was in Feb 2015 and was really addressing an issue in a production shopfloor environment where records were dropped along with some corruption --bottom line was working with Access BE using wireless connections.

Loss of connection while writing to an Access DB is a known issue, never fixed, and probably unfixable.

Don't use Wifi / WAN with an Access BE.

The best option is to move the BE to a SQL Server BE. That will absolutely solve this issue. If you must continue to use Access as the BE, then write CSVs to a directory on the server and have an Access app RUNNING ON THE SERVER watch for these CSVs and import them into the table. At least if the write to the CSV file is interrupted, it does not corrupt the BE.

Another thought if you must use Access BE

Some other methods.

1. Write a small "guard file" before you start the upload and delete it once
the upload is
complete. Could be just an empty file with an appropriate file name to
identify the file being
uploaded.
Don't process an upload if its "guard file" exists

2. Try to open the file for exclusive access from you import routine.
You shouldn't be able to while the file is still open and being written to.

3. Write the file to a temporary file name and rename it using a standard
convention once
fully written. Only process files with an appropriate file name.

and

A variation of 1. that T.......... uses for FTP upload:

Write a small "pilot file" once the upload is complete. Could be just an empty file with an appropriate file name to identify the file being uploaded.
Don't process an upload if its "pilot file" doesn't exist.

and

Are you still working on this project? If not, then suggestions are
academic. If so, then the first thing to do is split the database! Put a
Front End on each client station and leave the BE where it is.

IMO, next thing to do is convert the BE to either SQL Express or MySQL.
Incidentally, a company called Bullzip <http://www.bullzip.com> offers a
pair of great tools that convert Access databases to either MS SQL or MySQL
-- and they are free. Once the database is converted, set up a new instance
of the FE that uses ODBC to connect to the new database.

Depending on the complexity of the Access BE, converting the FE to address
the new database can be trivial (where forms and reports are bound directly
to tables), or more involved (converting Select data sources to named
queries, which will arrive in the new BE as Views).

In the case of SQL Express, you'll need SSMS (the database manager) or SQL
Bench (the MySQL database manager).

While "graduating" to a real DBMS on the back end, you can leave the
current (split) database in place, until you get the new system working.
Splitting the old database will help significantly in preventing
corruption. And as previously mentioned, you have to replace the wi-fi with
wired connections.

Migrating the current DB to a real DBMS won't take long, really.

 

[spikepl]

Thanks jdraw - that was useful and enlightening.

 

[GBalcom]

Agreed! Thank you Jdraw. At the bottom of the article, it mentions not using wifi at all though.....is wifi not an option, even with the SQL BE?

 

[Minty]

We use decent Wi-Fi internally on a surface pro i5 for Access FE with SQL BE and it's fine. We have just changed all our internal WiFi access points to shiny new ones 802.11n compatible ones, but is was perfectly usable before we updated them.

Where we have experienced an issue if with a 300Mhz building to building link not being very Access friendly, but we think this is a setup issue...

 

[jdraw]

GBalcom,

According to the discussion I mentioned above wifi is not an issue with SQL/MySQL/Oracle back end.