This shouldn't happen, surely?

Bureaucrats love outsourcing because it fixes costs. Outsourcing the hardware and support would have been seen as a perfect solution. No pesky budgets for hardware, accounting depreciation for computer assets, support and IT management salaries etc.

Very true. One could possibly see it as stealth privatisation... I wonder which other parts of the NHS will be outsourced next.:(

Aside from future doom and gloom, there is perhaps an overall bright side to this particular outsourcing; service level agreements. Now, when various systems go down, they have to be back up and running, or fines can be imposed. The outsourced company also appear keen to try to fix ongoing problem systems to stop downtime from recurring... Something the previous IS section pushed aside.

From a personal point of view, my issues will only worsen. I don't know the exact server set-up, but our servers are housed in an adjacent building. The new IS company intends to move them to somewhere more convenient for them, ie, miles away. That was the plan and for all I know, it may have already happened. But if it hasn't, I expect I'll reach retirement age before any of my forms manage to load...:rolleyes:

As long as my db can function (even if it is slow), I'm hopeful it will survive for long enough to serve its purpose; to show that it is needed, that it is improving customer service and saving money. It is only a trial in our patch of the NHS, but if the db does as I intend, money from a central piggy-bank could be found to develop a web-based app that can be shared across various divisions, not just ours.
 
And I thought the Navy-Marine Corps Intranet was bad...

Tay, you have my deepest sympathy. However, as you describe it, there might be some glimmer of hope.

You don't install an FE file. You just copy it, if you have a place to do so. At the end of your session, you can delete it. Ac2007 can use the Application.References to normalize itself with some startup code, if need be, provided you keep the correct file names and paths in a table in the DB. In that environment, all the directories would be normalized, because they probably used Symantec Ghost or something like that to make a master copy of their "gold standard" drive. They would then build a system by ghosting the gold disk to the new system's hard drive.

Just remember, if the FE is truly and purely an FE, there is really nothing to install. It's just a file. If you always copy it before opening Access and always delete it when the session is done, you are probably going to be able to make this work. Make a script that uses drive-letter mapping. Execute the script to copy the shared FE to your private area, then the script can launch the private copy of the FE. When the FE exits, the script can delete the FE.

If you have a "private" folder on a shared drive (probably, just an extension of your profile on that drive), as long as it differs from (a) the BE folder and (b) everyone else's folder, you'll have crappy performance because of HORRENDOUS network latency, but the database FE lock issues won't be so bad. Not good, just not SO bad.

What you can't have is a truly shared FE file. That way lies madness. By the way, from your description, I can verify something else for you. Like government contracts in the USA, your privatized support contract was DEFINITELY the low bidder. That description of services wouldn't even pass a USA bureaucrat's oversight.
 
you'll have crappy performance because of HORRENDOUS network latency, but the database FE lock issues won't be so bad.

It is still going to be trouble having the BE beyond the LAN. Access really doesn't like high latency connections between the FE and BE. It will break down repeatedly and records will be lost.

Before a record is saved the FE and BE communicate to discuss if anyone else has changed the record while the FE was editing. If this communication is too slow then the FE gives up and you get an error.

Tay pointed out from the beginning that the forms took forever to load so it does suggest a slow connection. It may also be from retrieving too many records but even if this was optimised the problems of slow connections are insurmountable in Access.
 
Sorry for coming back to this thread so late.:o

I've made no changes to the database recently (will do before Christmas), but overall, performance hasn't been terrible. I know I need to address some issues, but I have more pressing ones to attend to.

As security issues weren't seen as a likely source for concern (as the folder the db is located in has restricted access anyway), security was minimal. My current woes are that someone is 'dabbling'. First, it appears that the password was changed, then changed back. And the latest is that all back end tables have 'disappeared'. In light of two colleagues giving the password to two different depts, my concern is that someone with some Access knowledge is being naughty. However, could it just be coincidence? Is corruption likely to cause the error message 'invalid password' (- wasn't; retyped it several times then it was ok again)? And to delete all tables?

Guess I'll just have to beef up security and set user level permissions. I searched on these forums for 'mde' but the search results yield nothing. Aren't abbreviations searchable?:confused:
 
After getting the general gist of this thread I skipped to the end, so if what I suggest has been said alrady I appologise.

In the NHS and other bodies that do not users saving stuff on their hard drives the IT dept always sets up a folder on the server for each user where their documents are stored. This is usually in theHome folder. You could place the front end in there for each user and have a shortcut on the desktop pointing to this folder. That way each user will have their own front door to the application, this will prevent any data collisions and enevitable corruption issues.

If all users do not have Access on their machines you will need to make sure it is a runtime version. The only down side of this is that not only are you bringing the data across the network you are also bringing Access accross too.

One major advantage is that if the IT bods give you access to all users home folders you can distribute updates from your PC without any need to go round updating individual machines.
 
Thanks for replying. What you have suggested is what I'd been asking (badly) to see if this was a possibility. We do have our own 'drive' on the network in which we are allowed to save documents. Presumably, this is what you mean? The_Doc_Man also felt this would be an improvement on what I currently have to contend with, and I intend to take this path once I'm back at work following training next week.

Everyone has Access on their machines, although it seems that a handful of people have both Access 2002 as well as Access2. Yes, that's right.:eek: It seems to be the default version of Access for some users. It was a blast from the past to see that huge key logo! Those users can overcome this, however...

More oddities occurred this week when three users could not open this database. When you look at the files on 'My Computer', rather than it saying 'file type Microsoft Access' it says instead 'Microsoft Access2'; just for these users. Even if I open Access 2002 on their machines and try to open the db from there, it fails to open.
 
Everyone has Access on their machines, although it seems that a handful of people have both Access 2002 as well as Access2.

If you ever really NEED to know the difference at the VBA code level, check (I think) Application.Version, which will be numbers at least up to 12.0 (for Ac2007). It's just a string, not a floating-point number. The dot is just a dot, not a decimal point. If there were actually cases where you needed to know that version, it is possible. Ugly, but possible.
 

Users who are viewing this thread

Back
Top Bottom