Any way to detect a wireless connection and limit it?

[google]

Hello,
I am working on an Acc2003 app for my company. In the interest of
reducing chances of corruption due to unstable network connectivity, I
would like to either prevent users from running it through a wireless
connection, or limit their use to read-only. I have absolutely no idea
if this is possible, and if so, how. Is there any way from within
Access to get the list of routers they are connecting through?
Ideally, I'd like to keep a list of "accepted router names", pop up a
message telling them the database isn't supported through their current
connection, and direct them to use the thin client option (then, of
course, kill the app). Seems like this would be a good security
measure too, as it would prevent someone from copying the files and
taking them elsewhere to try to hack in to.

Any ideas?

Thanks!

[TC]

I don't see how you'd expect that to work. It's like saying, "When a
person knocks on my office door, I want to know if they came to the
building via a taxi, or a bus". No can do - because by the time that
they knock on your office door, the taxi or bus is long gone, and it's
too late to look out the window & see how they came!

I think you're going about this task the wrong way around. 99% of users
don't care *how* the software works - as long as it works. So, start
the app via a small script file that checks the user's PC has a copy of
the FE; downloads a copy if appropriate; then starts the FE. So it all
works automagically. Why then would a user spoend time trying to find a
different way to start the application? Using his wireless connection,
or anything else?

HTH,
TC (MVP Access)
http://tc2.atspace.com

[Arvin Meyer [MVP]]

There are several ways that you can limit connections. You will need a
dedicated database server for many of them. On the Access side, there isn't
much you can do without directly limiting users or workstations. You might
look to one of the networking newsgroups for answers involving the network.
--
Arvin Meyer, MCP, MVP
Microsoft Access
Free Access downloads
http://www.datastrat.com
http://www.mvps.org/access

<go****@darincl ine.com> wrote in message
news:11******** *************@i 40g2000cwc.goog legroups.com...

Hello,
I am working on an Acc2003 app for my company. In the interest of
reducing chances of corruption due to unstable network connectivity, I
would like to either prevent users from running it through a wireless
connection, or limit their use to read-only. I have absolutely no idea
if this is possible, and if so, how. Is there any way from within
Access to get the list of routers they are connecting through?
Ideally, I'd like to keep a list of "accepted router names", pop up a
message telling them the database isn't supported through their current
connection, and direct them to use the thin client option (then, of
course, kill the app). Seems like this would be a good security
measure too, as it would prevent someone from copying the files and
taking them elsewhere to try to hack in to.

Any ideas?

Thanks!

[Tim Marshall]

Arvin Meyer [MVP] wrote:

There are several ways that you can limit connections. You will need a
dedicated database server for many of them. On the Access side, there isn't

I write Access FEs for our Oracle systems and this is how the Oracle
DBAs accomplish preventing wireless access to the databases.

From my perspective, this is actually a very irritating limitation and
we're looking at getting our own Oracle server to avoid this wireless
limitation. It's incredibly limiting to be able to cart a laptop into a
meeting somewhere and be unable to generate reports and graphs on
various aspects of our operation or to be able to use hand held devices
to transmit information to workers who might be inside a boiler or
something.

Then again, the C/S nature of Oracle and, I would guess, MS SQL, makes
wireless type communications less fraught with danger?
--
Tim http://www.ucs.mun.ca/~tmarshal/
^o<
/#) "Burp-beep, burp-beep, burp-beep?" - Quaker Jake
/^^ "What's UP, Dittoooooo?" - Ditto

[TC]

Tim Marshall wrote:

Arvin Meyer [MVP] wrote:

There are several ways that you can limit connections. You will need a
dedicated database server for many of them. On the Access side, there isn't

I write Access FEs for our Oracle systems and this is how the Oracle
DBAs accomplish preventing wireless access to the databases.

Tim, I don't understand. How do your Oracle DBAs prevent wireless
access to what databases?

Cheers,
TC (MVP Access)
http://tc2.atspace.com

[google]

""When a
person knocks on my office door, I want to know if they came to the
building via a taxi, or a bus". No can do - because by the time that
they knock on your office door, the taxi or bus is long gone, and it's
too late to look out the window & see how they came!"

I'm not quite sure I follow your analogy. When they start the
application, I'm already doing some security checks, and kicking them
out if, for example, they aren't logged in to the network under the ID
that matches the Access user ID. *IF* I could do something similar to
a tracert and find the hops to the server, there's no reason I couldn't
do the same thing here. It'd be before they got to the point where
they would be editing any tables, which is the main concern. Even if
the wireless connection flaked out during the brief amount of time it
took them to read the "sorry, you must use the thin client from this
connection" message, I don't see how any corruption would be caused
since they wouldn't have any tables open for editing.

"So, start
the app via a small script file that checks the user's PC has a copy of

the FE; downloads a copy if appropriate; then starts the FE."

I'm already doing that, but I don't understand what that has to do with
whether or not they are connected wirelessly. The script does the
check, copies the file, and opens the DB regardless of how they are
connected (I'm using Tony Toews' Auto FE Updater, FWIW). If that is
the appropriate place to do the check, that is fine with me, but I'm
still clueless on how to figure out how they are connected, or if it
can even be done.

"Why then would a user spoend time trying to find a
different way to start the application? Using his wireless connection,
or anything else?"

It's easy enough to tell people "use the TC if you're connected
wirelessly", it's another thing to get them to remember that. If
there's a way to seemlessly use that method instead when connected
wirelessly, then all the better.

[google]

"this is actually a very irritating limitation and
we're looking at getting our own Oracle server to avoid this wireless
limitation. It's incredibly limiting to be able to cart a laptop into
a
meeting somewhere and be unable to ..."
Yes, I agree that not having the limitation at all would be ideal, but
for us, a CS setup isn't an alternative. Our HQ is very restrictive on
what we can put on our network. I can use spare workstations to host
remote sessions for remote and wireless users to use the DB, But
putting another server on the system (much less getting licenses for
one), is not something I can do. But the fact remains that wireless
connections do provide a less robust connection, and therefore the
chances of curruption from a wireless client is higher than that via
wired. Therefore, I'm considering workarounds to reduce this chance.
I'd even be happy with (or even prefer), the ability to allow them to
connect wirelessly, but keep them in read only mode. But I have no
clue as to how to detect how they are connected. To mirror TC's
question, how are you detecting that in your network?

Thanks!

[TC]

Yes, on reflection, I think that I have missed the point entirely.

Is this it: From within the code that is running in a front-end
database on the user's PC, you want to know if their connection to the
*back end* database, on some other PC, is via a wireless network
connection (as opposed to a wired connection)?

It is easy, using code within the FE database, to get the full
pathfilenam of the back-end database. Presumeably, that pathfilename
will be a UNC path (//server//share// or whatever it is), or a mapped
drive letter (X:/blah). Perhaps, given that UNC path, or mapped drive
letter, there's a win32 API which would tell you something about the
relevant transport layer.

If so, this would be a win32 question, not an Access one. "Given a UNC
path, or mapped drive letter, how do I determine whether there is a
wireless network connection to the end-point defined by that UNC path
or mapped drive letter?"

Yes? No?

TC (MVP Access)
http://tc2.atspace.com

[google]

"From within the code that is running in a front-end
database on the user's PC, you want to know if their connection to the
*back end* database, on some other PC, is via a wireless network
connection (as opposed to a wired connection)? "

Yes, that's exactly it. Sorry I wasn't more clear in the beginning.

"If so, this would be a win32 question, not an Access one."

Yes, but I'm hoping someone here would have already found a way. If
someone explains it in terms of VB, I can generally digest it. But I
fear I may not know how to apply what I may learn if given an answer
that pertains more to the inner workings of Windows. ;-) Through some
searching, I've found a couple other posts in the Access newsgroups
with similar questions, but they tend to stray off into discussions of
how instable wireless connections are, without addressing how to
prevent them from happening. :-/

[TC]

Ok, then I would definitely try asking in
comp.os.ms-windows.program mer.win32, for example. It's definitely a
win32 programming question, not so much an Access one. If someone gives
you an answer there, using win32 API programming calls, we can probably
translated that answer into Access VBA.

HTH,
TC (MVP Access)
http://tc2.atspace.com