Multiple Users - One Server - No BE/FE Required - Help

[Tony Toews [MVP]]

I am running into a problem (mind you, I am not a guru on anything related to
Access or networks). The database is on the server. My intent is to also
house the multiple FE's on the server as well as we don't want to install
items on our clients computers. When clients login to the server, there
specific FE fires open.

But please confirm that your clients will be using Terminal Server to
access your data. Your postings imply this but nowhere have you
actually stated this.

The good: I can open multiple FE's on the server itself (without loggin in
as the user) and the database responds just fine allowing edits, deletes, etc.


The bad: If I login as the various users, the first individual can get in,
but once some tries to access the same table, I get the "cannot lock table
"XXX" another user" error.

I have verified that the users have full permissions. Any thoughts?

Hmm, full permissions are usually the answer to that message.

(PS, I sent an email to your in regards to an Ostrosoft attachment error).

Yes, but I haven't gotten around to thinking about it.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm

 

[Rick Brandt]

I'm putting words in David's keyboard however anyone with network
privileges can take a copy of the backend home and review the data at
thier leisure.

And in a HIPAA compliant "paper system" anyone with access to the documents
can make a copy and take them home and review the data at their liesure.

And in a HIPAA compliant Micro-fiche system anyone with access to the
micro-fiche could take them home.

I have to believe that the thrust of HIPAA is providing reasonable security
from non-authorized users. What evil deeds *authorized* users do has never
been anything that can be controlled with any certainty.

 

[dbahooker]

GUNNY

SHUT THE **** UP AND START PREACHING ADP, BITCH

LOSE THE TRAINING WHEELS

MDB IS FOR CRIPPLES AND RETARDS

 

[dbahooker]

you _CAN_ do this with an Access Data Project

MDB doesn't run across wirless networks, WANs; VPNs, etc

MDB is for cripples and retards

move to SQL Server and Access Data Projects

 

[dbahooker]

Tony;

STOP SPREADING LIES BITCH

I HOPE SOMEONE THROWS A BRICK THROUGH YOUR WINDOW

ACCESS _DOES_ WORK GREAT OVER A WAN.
MDB DOES NOT WORK OVER A WAN.

LOSE THE TRAINING WHEELS YOU FAT LAZY SENILE ****TARD

 

[dbahooker]

oh David; that is mother ****ing precious.

is the same true for SOX?

ROFL

MDB doesn't work for HIPAA ROFLMAO

 

[dbahooker]

Wow, tony! I'm impressed!

next thing you'll be singing the praises of Access Data Projects!

-Aaron

 

[dbahooker]

just use ADP kid; it supports HIPAA, it supports WAN and Wireless and
VPN.
and you don't need to buy Terminal Server licenses for everyone

ADP is a porsche and MDB is a tricycle

-Aaron

 

[David W. Fenton]

[quoting me:]

They are not on a LAN, they will connect via internet.

Then you should use Windows Terminal Server and run the apps on your
server. Then all the clients would have is a shortcut for running
the Remote Desktop Client.

Thus, it is easier to
distribute one connection shortcut than what will be multiple FE
distributions over the next 12 months.

You can't run Access across the Internet, with front ends on one end
of the connection and back ends on the other. That just does *not*
work, and never could.

We 100+ customers, but, we only
forsee 10-20 simulataneous users. Some clients will login in 1-2
a week. Others will login 1-2 times a quarter. And when they do,
they probably won't be on longer than a few minutes at a time.
Right now, I foresee our server to be more than robust.

You haven't given the specs for it that I recall, but 2-4GBs of RAM
should easily cover that number of simultaneous users on Windows
Terminal Server.

Since they are not on LAN, but rather the internet, any thoughts
on why my FEs open locally but when multiples login from the
internet, the BE database is locked? I have checked user security
and the right read, write, edits, etc. are checked.

The BE could be locked for any number of reasons because that's
where the data edits are happening. Or you could be experiencing the
"open exclusive" issue, one which I've seen occasionally, but have
never actually figured out what causes it.

 

[David W. Fenton]

Why would network security not meet HIPAA rules?

Because the back end data files are available to the clients. If it
was just your company's employees, it would be OK, but once you open
up the database to access from clients, and store data for multiple
clients in a single Jet back end, you've got a problem, because one
client could see the data for another client.

One solution would be to encrypt data, but that's a real pain --
it's much easier to switch to SQL Server for your back end and get
actual security that would prevent cients from getting inappropriate
access to the data of others.

 

[David W. Fenton]

[quoting Rick:]

It can. However, my lack of knowledge on how to build a web based
program currently prevents me from doing a web based design. We
currently have a web based design (non access based), but I am not
strong enough to improve better on.

Web-based designs have their own challenges. It would have to be
HTTPS and even better would be if it could only be run over a VPN.

As long as you don't do any emailing, that would probably be safe
(email can't be HIPAA-compliant unless its encrypted).

 

[David W. Fenton]

And in a HIPAA compliant "paper system" anyone with access to the
documents can make a copy and take them home and review the data
at their liesure.

But the difference is who has access: employees or clients? The app
being described is for *client* access, and so far as I can tell,
the app has never been discussed except as having a single back end
for all clients. That would mean that one client (who has read/write
access to the folder where the back end is stored) would have access
to another client's data were they to take a copy of the MDB.

It's the fact that you've opened up the secure network to outside
entities that makes a Jet back end impossible to bring into HIPAA
compliance *unless* you have a separate back end for each client,
and each back end were stored in a different folder with access
rights only for the client the back end belonged to.

And in a HIPAA compliant Micro-fiche system anyone with access to
the micro-fiche could take them home.

Employees, yes. But not clients.

And if they take the stuff home, they are likely breaking the rules,
anyway.

I have to believe that the thrust of HIPAA is providing reasonable
security from non-authorized users. What evil deeds *authorized*
users do has never been anything that can be controlled with any
certainty.

No, the goal of HIPAA is to make sure that patient data is
protected.

But you seem to have missed the description of the app, where it's
serving CLIENTS not just EMPLOYEES.

 

[dbahooker]

David;

Re:
You can't run Access across the Internet, with front ends on one end
of the connection and back ends on the other. That just does *not*
work, and never could.



I CAN RUN ADP ACROSS THE PUBLIC INTERENT, VPN, WAN, LAN, WIRELESS

I'm sorry that you're stuck as a MDB-crybaby

ADP works _GREAT_ over the internet.

-Aaron

[quoting me:]

They are not on a LAN, they will connect via internet.

Then you should use Windows Terminal Server and run the apps on your
server. Then all the clients would have is a shortcut for running
the Remote Desktop Client.

Thus, it is easier to
distribute one connection shortcut than what will be multiple FE
distributions over the next 12 months.

You can't run Access across the Internet, with front ends on one end
of the connection and back ends on the other. That just does *not*
work, and never could.

We 100+ customers, but, we only
forsee 10-20 simulataneous users. Some clients will login in 1-2
a week. Others will login 1-2 times a quarter. And when they do,
they probably won't be on longer than a few minutes at a time.
Right now, I foresee our server to be more than robust.

You haven't given the specs for it that I recall, but 2-4GBs of RAM
should easily cover that number of simultaneous users on Windows
Terminal Server.

Since they are not on LAN, but rather the internet, any thoughts
on why my FEs open locally but when multiples login from the
internet, the BE database is locked? I have checked user security
and the right read, write, edits, etc. are checked.

The BE could be locked for any number of reasons because that's
where the data edits are happening. Or you could be experiencing the
"open exclusive" issue, one which I've seen occasionally, but have
never actually figured out what causes it.

 

[David W. Fenton]

My previous posting wasn't appropriate for bhipwell's environment
as it would appear he is running Terminal Server. Thus the user
doesn't have access to the network share.

Huh? How can someone run an Access app without having access to the
network share where the back end is stored?

 

[David W. Fenton]

[quoting me:]

Appreciate your feedback. In regards to HIPAA compliance, we are
receiving strong advice from a legal group who handles these
matters.

Do they understand how Jet/Access works? If they are OK'ing storing
data in Jet as HIPAA-compliant when the data file is going to be
accessible to multiple clients, then I think they likely do *not*
understand how Jet works.

In terms of 100+,
we have 100+ clients, but we cannot imagine more than 10-20
simulataneous logins. The program we are developing will only
require clients to login a couple times a week for the busiest
clients, a couple times a quarter for our smaller clients.

Then that should be fairly easy with a single Windows Terminal
Server.

Finally, I am looking at using the server/access model
versus the web based solution as myself, nor another person here
has strong enough knowledge on the web access sort of stuff.

Can you elaborate on the JetMDB and how to get users logging over
the internet to be able to use an FE stored on our server?

It's just Windows Terminal Server. They run Remote Desktop, connect
to your server, log on, and they have a desktop on your Terminal
Server, and they run the app from there, with a front end for each
user and a shared back end.

It's quite simple.

 

[dbahooker]

I applaud your reccomendation, David.

Now just go full circle and tell them that they can reuse their
existing forms and reports by using Access Data Projects.

-Aaron

 

[Tony Toews [MVP]]

Huh? How can someone run an Access app without having access to the
network share where the back end is stored?

They can get to the Access backend but they couldn't copy it to their
own computer.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm

 

[Rick Brandt]

But the difference is who has access: employees or clients? The app
being described is for *client* access, and so far as I can tell,
the app has never been discussed except as having a single back end
for all clients. That would mean that one client (who has read/write
access to the folder where the back end is stored) would have access
to another client's data were they to take a copy of the MDB.

Okay, given that description I agree with you. I was taking a general
interpretation of your statement "...you're probably not in HIPAA compliance
because you simply
can't secure a Jet back end sufficiently to meet HIPAA rules."

 

[David W. Fenton]

Okay, given that description I agree with you. I was taking a
general interpretation of your statement "...you're probably not
in HIPAA compliance because you simply
can't secure a Jet back end sufficiently to meet HIPAA rules."

Well, I was speaking to a particular person in a particular
situation that he'd already described.

But it's probably a good thing that you forced a full clarification
in the thread for those who come along and read it later.

 

[David W. Fenton]

They can get to the Access backend but they couldn't copy it to
their own computer.

But that's not relevant to HIPAA compliance. They shouldn't be able
to *see* other clients' data -- as soon as they can, you're out of
HIPAA compliance.