CAN 1 access application/mdb test to see if another mdb is open??? iow: can BE tell if FE is running

  • Thread starter Thread starter bobg
  • Start date Start date
B

bobg

G-D google, this IS a f'g followup!!!!
hi Rick;

simple. I have a startup form in the BE incase anyone wants to open
it.
the "startup" form tells them not to touch the BE, and quits.

problem is, that I need to extract some table properties from the back
end directly, and getobject actually executes my startup form.

so - I want the BE startup form to be able to see if the FE is running
before displaying the "go-away" message.

Bob
 
I would recommend that you look into other forms of
security for your backend. This one has obvious drawbacks.
BTW, Rick is right. As far as I remember, the LDB is your
only way to tell who is logged into the file, but I think
it doesn't store the location of where the user logged in
from.
 
Cheval;

tx also for your reply.

Let me add 1 point, and another Q;

I don't really care if anyone is logged in or not...
I only care if the BE opens when the FE is running or not...
So the ldb really isn't helpful; It's not important to me whether
someone's logged in - just whether the FE is running on any given PC,
if the BE is opened...

So - here's my next Q:
is there some way I can use a "user32" (or other) API to determine if
the FE is open? If so, can someone give me some usage hints....

also - these responses prompt me to re-think what I'm doing in the
first place.
Which is this:
The FE, when it opens, uses getobject to access the BE (which actually
opens an instance of the BE), along with GetHiddenAttribute to
determine if any given table is hidden. If it IS hidden in the BE,
then the hidden attribute is set in the FE.

I do all of this because apparently some ms programmer doesn't know
that when a LINKED table is marked as hidden - that it SHOULD STAY
hidden even after a refresh!!!

So - yes, all that I'm doing here is pretty stupid, but if ms left the
darn attributes the way they're set, none of this would be needed at
all.....

tia to anyone with some more ideas!!!!

Bob
 
Cheval;

tx also for your reply.

Let me add 1 point, and another Q;

I don't really care if anyone is logged in or not...
I only care if the BE opens when the FE is running or not...
So the ldb really isn't helpful; It's not important to me whether
someone's logged in - just whether the FE is running on any given PC,
if the BE is opened...

So - here's my next Q:
is there some way I can use a "user32" (or other) API to determine if
the FE is open? If so, can someone give me some usage hints....

also - these responses prompt me to re-think what I'm doing in the
first place.
Which is this:
The FE, when it opens, uses getobject to access the BE (which actually
opens an instance of the BE), along with GetHiddenAttribute to
determine if any given table is hidden. If it IS hidden in the BE,
then the hidden attribute is set in the FE.

I do all of this because apparently some ms programmer doesn't know
that when a LINKED table is marked as hidden - that it SHOULD STAY
hidden even after a refresh!!!

So - yes, all that I'm doing here is pretty stupid, but if ms left the
darn attributes the way they're set, none of this would be needed at
all.....

tia to anyone with some more ideas!!!!

Bob
 
(e-mail address removed) (bobg) wrote in
problem is, that I need to extract some table properties from the back
end directly, and getobject actually executes my startup form.
Click to expand...

You are right that using GetObject starts the whole Access GUI, but if you
want to read from a table, then just use Jet:

' open a jet database
Set dbBack = dbengine.Opendatabase("c:\data\backend.mdb", false, false)

'
strSQL = "SELECT Something FROM Somewhere WHERE Somehow;"
Set rs = dbBack.OpenRecordset(strSQL, dbOpenSnapshot, dbForwardOnly)

' read the info
dblSomething = rs!Something

' all done
rs.Close
dbBack.Close

Hope that helps


Tim F
 
hi Tim;
tx so much for your reply - I'm just getting back to this now...

Your solution was the very first thing I tried.

The problem is, I want to retrieve the "hidden" property of the
various tables IN THE BACKEND. (if you refresh linked, hidden tables
[in the FE], ms apparently doesn't know how to remember that those
tables were supposed to be hidden!)

So - I'm trying to use: GetHiddenAttribute to get that info.
GHA only works with objects, not database types - hence my use of
"getobject".

Tim - your suggestion would work great if I was trying to get
information stored IN the table. I'm trying to access properties OF
the table itself.

If anyone knows how I can get this information without opening a 2nd
instance of access - I'd really like to know how!!!!



Tim Ferguson said:
(e-mail address removed) (bobg) wrote in
problem is, that I need to extract some table properties from the back
end directly, and getobject actually executes my startup form.
Click to expand...

You are right that using GetObject starts the whole Access GUI, but if you
want to read from a table, then just use Jet:

' open a jet database
Set dbBack = dbengine.Opendatabase("c:\data\backend.mdb", false, false) [snip]
Set rs = dbBack.OpenRecordset(strSQL, dbOpenSnapshot, dbForwardOnly)
[snip]

Tim F
Click to expand...
 
(e-mail address removed) (bobg) wrote in
Tim - your suggestion would work great if I was trying to get
information stored IN the table. I'm trying to access properties OF
the table itself.
Click to expand...

Well, if you want to tamper with the GUI properties, then you'll just have
to open a GUI.

Tim F
 
hi again, Tim;

That's what I was afraid of - so that takes me back to my original
problem - which is how can I tell if the FE to an application is open
when the BE is opened in the "get object" scenario?

IOW: is there a way in vb - or using an api - that 1 access database
can tell if another access database is open?

tx again ia...
Bob
 
(e-mail address removed) (bobg) wrote in
That's what I was afraid of - so that takes me back to my original
problem - which is how can I tell if the FE to an application is open
when the BE is opened in the "get object" scenario?
Click to expand...

Oh dear -- I am getting an awful sense of deja vu here. The way I was
trained, all useful information is stored in fields in tables, and the only
way to access anything at all is via a field name, a table name, and a PK
value. I really cannot summon enough interest in alternative ways of
secreting stuff in a mdb file to think about it much.

Have you tried looking through the Containers and Documents collections --
is there something with tables and their properties there?

B Wishes


Tim F
 
Tim Ferguson said:
Oh dear -- I am getting an awful sense of deja vu here. The way I was
trained, all useful information is stored in fields in tables, and the only
way to access anything at all is via a field name, a table name, and a PK
value. I really cannot summon enough interest in alternative ways of
secreting stuff in a mdb file to think about it much.

Have you tried looking through the Containers and Documents collections --
is there something with tables and their properties there?

B Wishes


Tim F
Click to expand...

Tim;

I appreciate all your help (can't tx U enuf - but will try below)!
(last first)
Yes - I've tried EVERY freaking thing I could possibly think of. I've
looked at EVER object in EVERY collection, checked EVERY property
(that made any sense) - to no avail.

(and first, last)
I'm really not trying to "secret stuff in a mdb file". I just want to
RE-set a parameter in the database, that can be EASILY accessed with a
right click on a table's name.

So, you see - the thing I'm trying to access is NOT information that
would EVER go into a table.

I'm talking about properties of an object that are not, nor will ever
be stored as conventional information.

Again - I must stress my extreme frustration with microsoft - because
if it wasn't for their "feature" - I wouldn't be wasting all this
time....

I don't know if you've ever tried this - but -

IF you mark a linked table (in the FE of a FE/BE application), as
HIDDEN - where the corresponding linked table in the B.E. is also
HIDDEN (this is moot);
AND you need to refresh those links, (ie: the FE application was moved
to a different PC, or the mapped drive to the BE is changed)
THEN all "HIDDEN" properties on the linked tables in the FE are
LOST!!! (these properties are still preserved in the BE (again moot) -
but apparently ms programmers don't know how to save that little flag)
END IF

I'm only being so persistent with this because:
A) I'm not sure I've done a good job communicating the
bug/issue/problem.
B) I can't believe that so few people would have complained about this
that there isn't SOME solution.
C) if I tell access that I want something hidden - it SHOULD STAY
HIDDEN!!!

Tim - I can't possibly thank you enough for your time & energy
regarding this, but I must add:

D) I CAN'T BELIEVE YOU'RE THE ONLY ONE RESPONDING!!!!

It's mostly because of (D) that I keep wondering if it's me - having
trouble communicating the problem properly, so as to peak the interest
of others...
Or that I'm doing a poor job of using the right keywords in my search
for other's with the same issue...

I just don't know what to do next - and this MUST have a solution!

Doesn't ANYONE out care that their refreshed, linked, hidden tables
don't stay hidden?????

tia - Bob
 
(e-mail address removed) (bobg) wrote in
Again - I must stress my extreme frustration with microsoft - because
if it wasn't for their "feature" - I wouldn't be wasting all this
time....
Click to expand...
But it's a database program! Its one and only responsibility is to store
stuff in fields in records in tables, and to guard its integrity according
to the design schema. That's all. Nothing else.

Yes, I get frustrated by all the nonsense that comes around it --
autocomplete, subdatasheets, lookup fields and all the rest -- but the only
way to get anything decent done is simply to rise above and ignore it all.
Pretend it's not there. I have never, ever, found any reason to fill in a
Table Description field and I certainly would not dream of trying to access
a Field's Format property through a program. Stick to the knitting.

Some things are a genuine pain -- like defaulting numeric fields to a
DefaultValue of 0, which is a grand way of killing a new database until you
notice what it's doing. And some important stuff is missing, like triggers.
And a proper query-able catalog.

If you don't like the Access GUI, then there are plenty of other front ends
out there to manipulate a Jet database. Try Excel or Word or CorelDraw! or
Perl, whatever suits you better. But don't bother blaming the Access team
making it hard for you to do something that doesn't need to be done. If
it's a GUI feature, use the GUI to do it. If it's a data item, use SQL.

All the best


Tim F
 
Back
Top