Solved Is the Table you see in Access a Datasheet Form? Yes.

[MsAccessNL]

If I open a table and type in the immediate window: ?screen.activedatasheet.form.name, i get the Table name. The next step was to get all the properties of this table/form and if i could manipulate them. It appeared to work. So my question to the experts on this forum. Is a table view in reality a form in datasheet view?

Using: screen.ActiveDatasheet.AllowAdditions = False, seems to work.

Public Sub TableForm()

    Dim frm As Object
    Dim prp As Property
    'open a table first
    Set frm = Screen.ActiveDatasheet
    Debug.Print frm.Name
    For Each prp In frm.Properties
        Debug.Print prp.Name, prp.Value
    Next

End Sub

 

[tvanstiphout]

> can we make in this way an after update event on the table instead of using a datamacro?
Bad idea. If you can pull this off the AfterUpdate event would be on the form, not on the underlying table.

 

[MsAccessNL]

> can we make in this way an after update event on the table instead of using a datamacro?
Bad idea. If you can pull this off the AfterUpdate event would be on the form, not on the underlying table.

The question is, is the table you are seeing on your screen in reality a datasheet form?

 

[ebs17]

Is a table view in reality a form in datasheet view?

Yes, but this is not an access form as we know it, but a stripped-down version for the purpose of viewing Mur. And you don't really see a table, but a recordset of the table, which you notice, for example, because records are in a fixed order and you can switch from one record to the next, whereas this is quite complex for the real table in a query .

Can we make a class to set the properties to the table directly

Nothing sensible will work there.
Changes to table contents via action queries are not displayed immediately in the open table view, but only after a requery (F5). So there is visibly no reaction at the table level.

 

[MsAccessNL]

I adjusted the post, to make the question a clearer.

 

[arnelgp]

. Is a table view in reality a form in datasheet view?

I cannot tell.
there is No Form object that you see?
Only MS is knowledgeable to answer that question.

. It appeared to work.

some Properties are read-only.

 

[The_Doc_Man]

This question came up MANY years ago (LONG before the switch to Xenforo forum software) and the general idea was that yes, what you see in a table's datasheet view is actually a form that - if I recall this correctly - comes from a template file somewhere. But whether Access copies the template and dynamically tailors it to have the right number of columns and copies other properties from the table's Fields collection, ... who knows?

 

[arnelgp]

But whether Access copies the template

that does mean SSMS has a form when you open a table to view it's data?
i think it is more of a Datagrid control found on most C++, VB6, VB.Net and not a "form".
remember MSA is made from C++ or something.

 

[Edgar_]

Interesting question, Daniel. I love these kinds of threads.

So I opened some table. Then, if I debug the screen object from a module:

Sub testIt()
    Dim a As Object
    Set a = Screen
    Stop
End Sub

I get this:

ActiveDatasheet seems to be an object of type Form/T_activities. By the way, the table I opened is named "activities". You can see that ActiveControl is of type Control/TextBox. If I inspect the textbox object, I get a bunch of errors I will get if I try to access any of those members:

There are, however, some members I can access, they're so few I can write them here: Coltyp, ColumnHidden, ColumnOrder, ColumnWidth, ControlSource, ControlType, Enabled, Format, LayoutID, Locked, Name, OldValue, SelLength, SelStart, SelText, Text:

The rest will throw an error. That includes events:

Now let's take a look at the datasheet object (by the way, even though it's of type T_activities, because the table is called activities, I can't really do anything with that type, at least not in the tests I have done). There seems to be some interest in the events of this form object, so, let's take a look at them:

Well, surprisingly, the events seem to be available. In fact, most Form properties are available, here's a bunch of the properties:

We even have a recordset member there, if I try to automate it, it works:

Sub testIt()
    Dim f As Form
    Set f = Screen.ActiveDatasheet
    f.Recordset.MoveNext
End Sub

I guess the challenge here is make it trigger an event, I'll run it and see

Sub testIt()
    Dim f As Form
    Set f = Screen.ActiveDatasheet
    f.AfterUpdate = "=msgbox('that works yo')"
End Sub

Haha, it works. Nice one, Daniel.

 

[MsAccessNL]

Thanks Edgar, that’s exactly what i wanted to know, if i could trigger an event directly on the table.

When the table is linked and you exppand the subdatasheet, the rowsize of that particular row is made larger. (Click on the + sign in your activities table) .Can you see/find a property with wich you could set the individual row height?

 

[arnelgp]

Can you see/find a property with wich you could set the individual row height?

if it is a "datasheet", then there is only 1 Row height for the entire sheet.

 

[MsAccessNL]

if it is a "datasheet", then there is only 1 Row height for the entire sheet.

I understand, but the (linked) table datasheet is showing individual row Heights. So it’s possible. I am trying to find A way to get this done.

Like the position of a textbox in a continuous form, a lot of people are saying (for many years) that you can’t determine this, but it’s just one of the form properties.

 

[The_Doc_Man]

that does mean SSMS has a form when you open a table to view it's data?

Just to be clear, ArnelGP, my comment was limited to "pure" Access as opposed to anything involving an active SQL back-end. AND the discussion was a LONG time ago. I found where I had discussed this same topic in 2009. It may be that what we are seeing is that we NEVER actually open a table anyway. In a table's datasheet mode we open a table-type recordset and that means that we use whatever Access uses for QUERY display.

EDIT: Don't know if what you want is there, and it is SURELY dangerous to muck about in it, but look at...

C:\Users\yourname\AppData\Roaming\Microsoft\Access\ACWZUSRnn

DO NOT CHANGE ANYTHING IN THAT FILE. If you do, it is re-install time.

 

[Edgar_]

Can you see/find a property with wich you could set the individual row height

Yes. When you click the + button to the left, you get a subform control. The subform control does not provide a RowHeight property, but the form inside the subform control does. Therefore, the syntax is: Form.SubformControl.Form.RowHeight

There are just too many ways to build the reference, in the attached picture, you can see I'm using the last item in the Controls member, but I could use its name, I could also use any syntax for that, you can use bangs, dots, defaults, explicit, any way you like. The challenge will be managing those subforms, because they only become accessible when they're open, and their name is chosen by Access by default. In my case, they're called "Secundario0", "Secundario1"... by order of appearance.

After this demonstration, it's clear that table views use a Form object that can be automated. Another challenge here is giving them a code module, for example, in order to set the HasModule property of a form, it has to be in Design View and then be saved. How you manage will be interesting to see.

 

[isladogs]

Thanks Doc

RE:: C:\Users\yourname\AppData\Roaming\Microsoft\Access
I've not looked in this folder for years but there are 2 very useful files in there:

I defintely agree that the two highlighted files are not to be deleted
I also have a large number of old System.mdw files that I haven't used for years & can almost certainly be deleted

 

[isladogs]

Thanks also to Edgar
I found your earlier post fascinating. I ran the same tests on a table with similar results except I was unable to get a message box to trigger

EDIT 1:
The message did trigger but only after I clicked out of the next control

EDIT 2:
This is an interesting way of making a table read only without needing to use constraints

 

[The_Doc_Man]

RE:: C:\Users\yourname\AppData\Roaming\Microsoft\Access

If you look at C:\Users\yourname\AppData\Roaming\Microsoft\?? where ?? is any of the members of Office, you would find other useful files. For instance, if you have custom text style definitions for Word, they are in this path. Excel has something in its path, too. It is unwise to diddle around with ANY of the files that have the name "template" or "wizard" (or an abbreviation thereof) in that area, but that is where MS keeps the automated things like wizards and other behind-the-scenes stuff. There is also something for "old" Outlook, but "new" Outlook doesn't use the COM concept so don't look to change Outlook behavior from there.

 

[Pat Hartman]

This has nothing to do with Access. EVERY RDBMS must have a way of rendering a view of stored data even if the RDBMS does not provide an application interface the way Access does.

Unlike flat files, with a RDBMS, you are NEVER looking at raw data. You are always looking at data retrieved by a query. The naked bits and bytes are read from the hard drive by low level IO routines and put together in a way that makes sense. That query may select all columns and all rows as happens when you "open" a table in DS view, but in reality, you are looking at a query.

 

[sonic8]

This has nothing to do with Access. EVERY RDBMS must have a way of rendering a view of stored data even if the RDBMS does not provide an application interface the way Access does.

Absolutely!
I still remember the time of my very first steps with a "real" database, Oracle in my case, where data would be simply output to a command line (like) UI.- Of course no in-place edits possible there, but it still was a representation of the data in a table but it was retrieved by a query.

 

[isladogs]

True . . . but that wasn’t what this thread asked. The datasheet representation of both table and (therefore) query is in fact a datasheet form and can be made to respond, at least in part, to form events and properties.