fEnumDomainUser s and LDB Viewing on 97 split DB w/ distributed FE

[Pat]

Hello,
Two questions - hence the weird subject.

First, anyone had luck with the Enumerating user accounts in a NT Domain
module by Dev Ashish on Access Web
(http://www.mvps.org/access/api/api0058.htm). I get "true" as the only
return.

Also, I am developing my first split database - BE to reside on a file
server and the FE to be distributed (and updated with Tony Toews incredibly
handy Auto FE Updater). However, in playing with the split today, I
realized that the LDB will reside on each user's machine. So, my plans to
read the LDB for logged in users is scrapped.

For me, the distributed FE far outweighs the advantage of seeing who's
logged in. But, I'm hoping that, maybe, there is a trick I haven't yet come
across (aside from upgrading to A2K!). ??

Any assistance is appreciated.
Thanks
Pat

[Larry Linson]

What were you going to do with the information about who was logged in?
Perhaps there is another way to accomplish it. You can, assuming you secure
the DB so that people have to log in with a userid and password, write your
own log as users start and quit the application; or, you could code an
automatic quit based on data in the backend that could only be updated by
the administrator; or some other thing.

I have implemented a periodic check of a central "communicat ion" table in
both an Access client to a server database and an Access front-end in a
multiuser environment to allow the adminstrator to, first, give warning and
then, to force users off before shutting down for maintenance or other
purposes. That code is in the client app or the front end.

Larry Linson
Microsoft Access MVP

"Pat" <pa*@noemail.ih atespam.bum> wrote in message
news:vv******** ********@twiste r.austin.rr.com ...

Hello,
Two questions - hence the weird subject.

First, anyone had luck with the Enumerating user accounts in a NT Domain
module by Dev Ashish on Access Web
(http://www.mvps.org/access/api/api0058.htm). I get "true" as the only
return.

Also, I am developing my first split database - BE to reside on a file
server and the FE to be distributed (and updated with Tony Toews incredibly handy Auto FE Updater). However, in playing with the split today, I
realized that the LDB will reside on each user's machine. So, my plans to
read the LDB for logged in users is scrapped.

For me, the distributed FE far outweighs the advantage of seeing who's
logged in. But, I'm hoping that, maybe, there is a trick I haven't yet come across (aside from upgrading to A2K!). ??

Any assistance is appreciated.
Thanks
Pat

[Pat]

Excellent question. The db will not be secured with workgroup security. I
was mostly considering it as a "just in case" feature so, if I did need to
take the db down, I could know which connected user(s) I needed to track
down.

I was basically trying to side-step the additional effort of creating a
timer-based check, with which I could also force someone out. I just didn't
think I needed to go that far. I suppose I could still create a log table
on login/logout for each user to track who is in, but I was hoping there
might be something already out there.
"Larry Linson" <bo*****@localh ost.not> wrote in message
news:JB******** ***********@nwr ddc01.gnilink.n et...

What were you going to do with the information about who was logged in?
Perhaps there is another way to accomplish it. You can, assuming you secure the DB so that people have to log in with a userid and password, write your own log as users start and quit the application; or, you could code an
automatic quit based on data in the backend that could only be updated by
the administrator; or some other thing.

I have implemented a periodic check of a central "communicat ion" table in
both an Access client to a server database and an Access front-end in a
multiuser environment to allow the adminstrator to, first, give warning and then, to force users off before shutting down for maintenance or other
purposes. That code is in the client app or the front end.

Larry Linson
Microsoft Access MVP

"Pat" <pa*@noemail.ih atespam.bum> wrote in message
news:vv******** ********@twiste r.austin.rr.com ...

Hello,
Two questions - hence the weird subject.

First, anyone had luck with the Enumerating user accounts in a NT Domain
module by Dev Ashish on Access Web
(http://www.mvps.org/access/api/api0058.htm). I get "true" as the only
return.

Also, I am developing my first split database - BE to reside on a file
server and the FE to be distributed (and updated with Tony Toews

incredibly

handy Auto FE Updater). However, in playing with the split today, I
realized that the LDB will reside on each user's machine. So, my plans to read the LDB for logged in users is scrapped.

For me, the distributed FE far outweighs the advantage of seeing who's
logged in. But, I'm hoping that, maybe, there is a trick I haven't yet

come

across (aside from upgrading to A2K!). ??

Any assistance is appreciated.
Thanks
Pat

[Emile Gillespie]

"Pat" <pa*@noemail.ih atespam.bum> wrote in message
news:vv******** ********@twiste r.austin.rr.com ...

Hello,
Two questions - hence the weird subject.

First, anyone had luck with the Enumerating user accounts in a NT Domain
module by Dev Ashish on Access Web
(http://www.mvps.org/access/api/api0058.htm). I get "true" as the only
return.

Also, I am developing my first split database - BE to reside on a file
server and the FE to be distributed (and updated with Tony Toews incredibly handy Auto FE Updater). However, in playing with the split today, I
realized that the LDB will reside on each user's machine. So, my plans to
read the LDB for logged in users is scrapped.

For me, the distributed FE far outweighs the advantage of seeing who's
logged in. But, I'm hoping that, maybe, there is a trick I haven't yet come across (aside from upgrading to A2K!). ??

Any assistance is appreciated.
Thanks
Pat

Best place to get answers is at the official MVP site:
http://mvp.org
Emile Gillespie MVP

[Pink Panther]

Pat,

Well the 'backend' on your file server will create a ldb when a user
connects to it unless you are using unbound forms or some kinds of
stateless data display method on your front end (which I doubt you
would be, but hey you never know). You can just interogate that (the
ldb).

Why don't you use Microsofts Msldbusr.dll - this dll can be used to
interogate the ldb file and return all sort of info.

Do a search for Msldbusr.dll on google or download the Msldbusr.exe
and consult the help documentation.

If you want some sample code for how it's used just post back and I
put it on the NG.

Otherwise just use the LDBView.exe to check the .ldb file (that way
you don't need to write a line of code).

Peter

"Pat" <pa*@noemail.ih atespam.bum> wrote in message news:<vv******* *********@twist er.austin.rr.co m>...

Hello,
Two questions - hence the weird subject.

First, anyone had luck with the Enumerating user accounts in a NT Domain
module by Dev Ashish on Access Web
(http://www.mvps.org/access/api/api0058.htm). I get "true" as the only
return.

Also, I am developing my first split database - BE to reside on a file
server and the FE to be distributed (and updated with Tony Toews incredibly
handy Auto FE Updater). However, in playing with the split today, I
realized that the LDB will reside on each user's machine. So, my plans to
read the LDB for logged in users is scrapped.

For me, the distributed FE far outweighs the advantage of seeing who's
logged in. But, I'm hoping that, maybe, there is a trick I haven't yet come
across (aside from upgrading to A2K!). ??

Any assistance is appreciated.
Thanks
Pat

[Pat]

Chuck,
Thanks for the reply. I'm actually calling the function in the debug window
right now. If I run it with no arguments, I get a return of admin users on
my machine, then "true" at the end of the list. When I run it with the
network domain name, all I get is true.
??
"Chuck Grimsby" <c.*******@worl dnet.att.net.in valid> wrote in message
news:u1******** *************** *********@4ax.c om...

Dev's code will work, but it has all it's information routed to the
debug window. You will want to change that to printing to somewhere
you can use/see it.

"Function fEnumDomainUser s_Level2" returns a Boolean, which is where
you're getting that "True" from. Change it's return to "As String"
and then replace every instance of "Debug.Prin t" to
"fEnumDomainUse rs_Level2 = fEnumDomainUser s_Level2 & " <whatever> " &
vbNew line"

Example:

Debug.Print "Home Directory: ", fStrFromPtrW(.u sri2_home_dir)

becomes:

fEnumDomainUser s_Level2 = fEnumDomainUser s_Level2 & _
"Home Directory: ", fStrFromPtrW(.u sri2_home_dir) & _
vbNewLine
"Sub sPrintAccountIn fo" will also need to be changed to a function
that returns a string, and debug.print statements changed to
"sPrintAccountI nfo & sPrintAccountIn fo & " <whatever> " & vbNewLine"
in the same method as above.

You will *not* want to return all that information however, so just do
it on the lines you want to use, then comment out the rest.
On Wed, 22 Oct 2003 01:58:51 GMT, "Pat" <pa*@noemail.ih atespam.bum>
wrote:

Hello,
Two questions - hence the weird subject.

First, anyone had luck with the Enumerating user accounts in a NT Domain
module by Dev Ashish on Access Web
(http://www.mvps.org/access/api/api0058.htm). I get "true" as the only
return.

Also, I am developing my first split database - BE to reside on a file
server and the FE to be distributed (and updated with Tony Toews incrediblyhandy Auto FE Updater). However, in playing with the split today, I
realized that the LDB will reside on each user's machine. So, my plans toread the LDB for logged in users is scrapped.

For me, the distributed FE far outweighs the advantage of seeing who's
logged in. But, I'm hoping that, maybe, there is a trick I haven't yet comeacross (aside from upgrading to A2K!). ??

Any assistance is appreciated.
Thanks
Pat
--
A Fanatic Is One Who Can't Change His Mind And Won't Change The

Subject.

[David W. Fenton]

pa*@noemail.iha tespam.bum (Pat) wrote in
<vv************ ****@twister.au stin.rr.com>:

[]

Also, I am developing my first split database - BE to reside on a
file server and the FE to be distributed (and updated with Tony
Toews incredibly handy Auto FE Updater). However, in playing with
the split today, I realized that the LDB will reside on each
user's machine. So, my plans to read the LDB for logged in users
is scrapped.
Well, you want to use the LDB on the server, the one for the shared
MDB. All you then need is to get the name of the back end and then
you're set. Here's a function that does the job:

Public Function getBackEndPath( strTableName As String) As String
' DWF, CREATED ?, REVISED 2001/07/26
' RETURNS vbNullString WHEN NOT A LINKED TABLE
Dim rs As Recordset
Dim db As Database
Dim strDatabase As String

Set db = CurrentDb()
Set rs = db.OpenRecordse t("SELECT MSysObjects.Dat abase, _
MSysObjects.Nam e FROM MSysObjects _
WHERE (((MSysObjects. Name)='" & strTableName & "'));")
If rs.RecordCount = 0 Then
MsgBox "Error in 'getBackEndPath ()'. " _
& strTableName & " not found in MSysObjects."
getBackEndPath = "ERROR"
Else
rs.MoveFirst
If IsNull(rs!Datab ase) Then
strDatabase = vbNullString
Else
strDatabase = rs!Database
End If
End If

rs.Close
Set rs = Nothing
End Function

Another method is:

Mid(CurrentDB.T ableDefs([linked table name]).Connect,11)

That throws error 3265 when the table is not found, so you might
wrap it in a function with an error handler.
For me, the distributed FE far outweighs the advantage of seeing
who's logged in. But, I'm hoping that, maybe, there is a trick I
haven't yet come across (aside from upgrading to A2K!). ??

Looking at the right LDB will take care of the problem.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc