MVP's - MessageBox Question

[Dom.]

Hello All,

I two questions for all MS Access professionals and
they are as follow:
Q1: Is there anyway on a multi-user database to be able to
send a message to another user who's logged on.
Example: If you have a listbox displaying all the users
that are logged on and you choose one of the users, can
you send a message using the MsgBox to that user?
Q2: How long does it take to build a database with custom
security forms but medium in complexity?

Thank you all for your help.
Sincerely;
Dom

 

[Ben]

For question 1, check out
http://www.mvps.org/access/api/api0008.htm on Dev
Ashish's site. It will give you the network user name.
You can then use netset through WSH to send them a
message.
Can't tell you much about question 2, its going to depend
on a LOT of factors.
HTH

 

[John Crighton]

Or, (for the first question), you could have a "messages"
table, and have the Main Menu (or Switchboard) in your
app check the table for messages using the ontimer event.
The table would obviously consist of user names and a
space for messages.

The OnTimer event would keep quiet if the message field
was "", and send a message using msgbox if there was
something there.

A good thing about doing it this way, is that even if a
user isn't logged on, they'll get the message when they
do log on. If you don't want this to happen, then you
could have a third "time" field to record the time the
message was posted, and have it discarded if it's too old.

 

[Larry Linson]

Q2: How long does it take to build
a database with custom security forms
but medium in complexity?

If you mean to implement your own security instead of using Access security,
the answer would be "far longer than its worth" because you just can't
implement security in your own database that is as good as Access security
(even though Access security itself can be broken with a modest
expenditure).

Seriously, even with great detail about a database, it is difficult to
predict how long you'd take to create it yourself, much less for someone
else. And there is very little detail in your description.

In a previous incarnation as a mainframer in the contract services business,
I observed (and my organization concurred) that if you have a good set of
user requirements, you can make a reasonable estimate of the design phase of
software development and create a test plan; if you have a good design, you
can make a reasonable estimate of the development/implementation phase and
create test scenarios; estimating the testing and correction itself is very
imprecise because you would have to know how good the software produced by
the implementation phase turned out, and that is what testing is intended to
determine. How many times you have to execute the tests, submit the things
that need fixing, re-execute the tests, etc. willl determine the time and
effort of the test phase.

So, in short, if you've done something similar before and are realistic
about your capabilities, you can develop in phases with some hope of your
estimates (aka "educated guesses") being within the realm of reason.

But, the "devil's in the details" when it comes to estimates.

Larry Linson
Microsoft Access MVP