Table description

[ecawilkinson]

Interestingly, you can get to the table description like this as well:

db.Containers("Tables").Documents("YourTable").Properties("description")

Oddly, if the description is blank, then Access will tell you that this property does not exist, but as soon as you give it a description, you can access it. That means, in code, you would have to create it first.

HTH,
Chris

 

[KenHigg]

Interestingly, you can get to the table description like this as well:

db.Containers("Tables").Documents("YourTable").Properties("description")

Oddly, if the description is blank, then Access will tell you that this property does not exist, but as soon as you give it a description, you can access it. That means, in code, you would have to create it first.

HTH,
Chris

I am simply trapping for error code 3270 and doing a resume next.

BTW - Found out how to make it work: You have to use a db object for some reason. This works:

Dim doc As DAO.Document
Dim db as Database

Set db = CurrentDB

With db.Containers!Forms

 For Each doc In .Documents
   MsgBox "Form " & doc.Name & " - " & doc.Properties("Description")
 Next doc

End With

Of course this code will error if there is no value in the form description in which case you trap for error 3270 and do a resume next...

Next issue please.

 

[gemma-the-husky]

Ken, i was going to post that comment you just made

I keep getting errors just using currentdb - i have to

set dbs = currentdb, or something first, then it works - seems very strange


---------
ken, also not sure if you missed my earlier post - i am sure you can ADD a CUSTOM property to a table, to do whatever you want.


---------
finally, got my database checker working now. It checks clients back ends, against my master and reports anything wrong - ie fields/indexes set differently.

 

[KenHigg]

Ken, i was going to post that comment you just made

I keep getting errors just using currentdb - i have to

set dbs = currentdb, or something first, then it works - seems very strange


---------
ken, also not sure if you missed my earlier post - i am sure you can ADD a CUSTOM property to a table, to do whatever you want.


---------
finally, got my database checker working now. It checks clients back ends, against my master and reports anything wrong - ie fields/indexes set differently.

Must be something to do with currentdb being a function - ?

I have not created a custom property for an object like a table but I do create a custom 'database' property to manage front end versions. Good to know you can -

 

[ecawilkinson]

BTW - Found out how to make it work: You have to use a db object for some reason

That was why I said "Interestingly, you can get to the table description like this as well". I figured you would realise that the code I posted works for Forms, too.

Chris

 

[ecawilkinson]

I've never managed to get an proper official explanation as to why you need to use:

dim db as database
set db = currentDB

It seems to be rule that CurrentDB is good only for the line it is on. After that, it loses its connection to the underlying DB.

Chris

 

[Banana]

I wonder if it's reasonable to make db a public variable and set it at the startup?

If you happen to use another database, just create a local variable to set that database to.

 

[KenHigg]

Here's my thinking; CurrentDB is a function. From what I know a function merely returns values. Is has no peristance. However when you need to loop through an objects properties that are enumerated, something has to keep up with which property you're on as you loop. So the 'for each' works in conjuction with the object to do this. Something that could not be done with a function... whew. Hope that made sense and is somewhere close to correct -

 

[KenHigg]

So.....

Would either of you know how to check to see if a property exists before you try to access it and get the error?

 

[Banana]

I think you'd just trap for the error and resume next...

 

[gemma-the-husky]

banana - yeah you can do that - make a recordset persistent in an app

in fact, its a suggestion from MS to improve performance - i generally have a dummy table, and open a connection to it in the switchboard open, and only close ir in the switchboard close - its supposed to make access more efficient because its not having to keep reopening the dbs (or some such)

one of the suggestions in

http://support/microsoft.com/kb/889588

 

[gemma-the-husky]

Ken

Back to your original posting, i have now found that having entered a description you cant clear it programmatically by setting it to a zls.

I presume you have to delete the property instead

 

[KenHigg]

I've tinkered with it as well and just delete it. Wonder why it can't be a zls?

 

[gemma-the-husky]

i have had that with forms - perhaps thats the same thing

if you have an unbound form, its ik

once its bound, you cant make it unbound by setting the recordsource to a zls - access doesnt like it

What i wanted was to change a form for multiple use, changing the recordsource as appropriate -all ok until you try to delete the source ... then you cant

 

[Banana]

Hmmm.

I'm pretty sure I did set some of my forms' recordsource to zls before with no problem.... Will have to dig it up.

Regarding the description property, I wonder if because it's more object than a variable, setting description to nothing or null would work?