By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
424,962 Members | 1,767 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 424,962 IT Pros & Developers. It's quick & easy.

Problem: Network programming, OpenWorkspace?

P: n/a
Hello,

This is a question regarding MS-Access programming.

1. Network environment:
I got a room with 50 people answering the phone and logging the topics
of the incoming calls. Each has a PC, and the PC's are connected by
LAN to a Windows 2000 server PC.
2. Software Environment:
I built a small MS-Access database program which has the topics as
YES/NO fields. There are also a date/time field and a COMPUTERNAME
field for each logged call. Currently all of the users are opening this
program, which resides on a shared-location on the server, and feeding
directly to the server.

3. My wishlist:
I want to make a program which resides locally in a shared location on
each of the user's computers, and feeds to a database local to the
user's computer. At some instance, I, the network-administrator, will
have a program which logs into each of the shared locations of the
user's computers, opens the current users' database and harvests
their data to my own database table by way of SQL INSERT INTO.

4. My problems:
These shared locations, of the users, are protected by a
login/password. I must keep the login/password on. I need a
programmatic way to log into the current shared location. How do I do
it? OpenWorkspace only handles the password of the user in ACCESS
itself, not in the network. Do I have to use DDE/SendKeys to handle the
dialog being opened when I log in manually?

Thanks in advance,
Max.

Aug 12 '06 #1
Share this Question
Share on Google+
1 Reply


P: n/a
<mp*****@gmail.comwrote in message
news:11*********************@m73g2000cwd.googlegro ups.com...
Hello,

This is a question regarding MS-Access programming.

1. Network environment:
I got a room with 50 people answering the phone and logging the topics
of the incoming calls. Each has a PC, and the PC's are connected by
LAN to a Windows 2000 server PC.
Ok
2. Software Environment:
I built a small MS-Access database program which has the topics as
YES/NO fields. There are also a date/time field and a COMPUTERNAME
field for each logged call. Currently all of the users are opening this
program, which resides on a shared-location on the server, and feeding
directly to the server.
Not optimum, but go on...
3. My wishlist:
I want to make a program which resides locally in a shared location on
each of the user's computers, and feeds to a database local to the
user's computer. At some instance, I, the network-administrator, will
have a program which logs into each of the shared locations of the
user's computers, opens the current users' database and harvests
their data to my own database table by way of SQL INSERT INTO.
Why? You are already getting all of the data in a central database with no
additional effort. The only thing you should do is split your current app. One
file with just the tables goes on the shared server location and you give each
user their own copy of a front end file that contains all other objects and
links to the data file.

This way each user runs their own applicaiton file, but all data is stored in
one central location. It is trivial to modify the app so that each user's
network ID is stored when they create or modify records if that is what you are
going for.
4. My problems:
These shared locations, of the users, are protected by a
login/password. I must keep the login/password on. I need a
programmatic way to log into the current shared location. How do I do
it? OpenWorkspace only handles the password of the user in ACCESS
itself, not in the network. Do I have to use DDE/SendKeys to handle the
dialog being opened when I log in manually?
It's a bad idea. Just don't do it. The split app with a single data file is
the standard for multi-user Access applications. The only time to consider
something like what you are describing is when the users aren't on the same
network so changes have to be consolidated via a separate process. As long as
they are all on the same LAN there is nothing to be gained by doing this.

--
Rick Brandt, Microsoft Access MVP
Email (as appropriate) to...
RBrandt at Hunter dot com

Aug 12 '06 #2

This discussion thread is closed

Replies have been disabled for this discussion.