Solved Is the Table you see in Access a Datasheet Form? Yes. (1 Viewer)

[sonic8]

...but that wasn’t what this thread asked.

Well, the question was: Is a data sheet a data sheet. - The very unsurprising answer is: Yes.

 

[arnelgp]

Well, the question was: Is a data sheet a data sheet. - The very unsurprising answer is: Yes.

the original question was.. is the table you open (to view its records) in datasheet form.
well, the default CurrentView property is 2 (acCurrentView enum, 2 = datasheetview).

 

[ebs17]

if i could trigger an event directly on the table

Table level events occur in the database engine (ACE), not in a displaying form. Therefore, DataMacros were introduced that can implement something like this. However, their overall introduction is not yet convincing.

Above it sounds more like the aim is to automate the display of SubDatasheets, apparently as a replacement for proper subforms.

I know that the SubDatasheet property is generally switched off because it is a performance brake, because it is nothing other than constantly executing a query with links to other tables, even if their information is not needed at all. This then involves some overhead for display and keeping the display ready.

So I would ask @MsAccessNL the question: What is the ACTUAL reason for the concern?
Who wants or needs to work in tables in the table view when there are forms? Academic knowledge is all well and good, but where do you want to find the practical use?

 

[MsAccessNL]

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

View attachment 112807
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.

screen.ActiveDatasheet.SubdatasheetHeight = 300

Works to make the height smaller, but you can't make it bigger then the original Height. It's interesting that you can get a subform into a datasheet form, but not into the detail section of a continuous form..

 

[arnelgp]

but not into the detail section of a continuous form.

what you can do is add DblClick event on the PK and on its action, Open a Related Form.

 

[MsAccessNL]

I know that the SubDatasheet property is generally switched off because it is a performance brake, because it is nothing other than constantly executing a query with links to other tables, even if their information is not needed at all. This then involves some overhead for display and keeping the display ready.

I believe this is no longer true, based on the info of this post. The subdatasheet is only activated when you open the Table (we can now call it a Table form).I presume that most applications don't work with the table view. The data in a used form is not comming from the Table, but from somewhere else. (The table itself has a recordsource). The overhead issue with subdatasheets, does not apply (i think..). Unless you open the table to view the data.

 

[ebs17]

Your faith with all honor.

One of the very first points I learned when dealing with performance in queries is that SubDatasheets are a performance brake and should be switched off immediately. You read above: Every table access is a query, and the properties you set always have an effect, regardless of whether you notice them or not.

In my opinion, SubDatasheets are just a crutch for beginners, comparable to lookup fields in tables - nice for initial success, then extremely hindering when it comes to proper programming. Programming beginner aids beyond their intended purpose will then regularly run into problems.

 

[MsAccessNL]

Your faith with all honor.

One of the very first points I learned when dealing with performance in queries is that SubDatasheets are a performance brake and should be switched off immediately. You read above: Every table access is a query, and the properties you set always have an effect, regardless of whether you notice them or not.

In my opinion, SubDatasheets are just a crutch for beginners, comparable to lookup fields in tables - nice for initial success, then extremely hindering when it comes to proper programming. Programming beginner aids beyond their intended purpose will then regularly run into problems.

I don't think you get the essence of this post. A table isn't a table, it's a form. Properties of a form are not activated if the form isn't opened. Like in Sql server. You Create a table and then you can have a view of the table. We can better use the name TableView instead of Table.

 

[ebs17]

A table isn't a table, it's a form.

... and at night there is no nuclear fusion in the sun - it is dark.
This convinces me that I don't understand anything here.
I wish luck to those who understand.

 

[Pat Hartman]

OK, don't tell us the actual objective.

 

[The_Doc_Man]

A table isn't a table, it's a form.

No. A table is a table. What you SEE when you click the appropriate icons is a "quick-and-dirty" table-type recordset based on the equivalent of the query "SELECT * FROM table;" (no WHERE, HAVING, ORDER BY, GROUP BY, etc.) and displayed through a datasheet form.

Remember that you are using the Access interface, which means everything you see comes through the Component Object Model, which imposes structure on top of whatever is "reality" for that object. COM is how you can manipulate spreadsheets or documents through application objects. COM exposes methods and content via Office standards. Access uses COM just like every other Office member (except for "new" Outlook.)

Edgar's excursion was ALSO an exploration of COM interfacing. You have to recognize that we don't see reality even with that deep dive. We see the reality of the COM interface. He found some truly interesting things. (Thanks, Edgar!!!) But the reality he saw was the details of the COM view of the table he explored. If you look at it closely enough you would realize that Edgar traversed a TREE VIEW of the LOGICAL structure of that table. We have clues but no proof of the physical structure.

Office is NOT open-sourced so we don't know exactly how they do what they do. We have some good ideas, but the inner workings remain hidden.

 

[Edgar_]

I made a video to show how to do change row height for the subform and add some events to the main form.

I don't have a microphone to explain what is going on in detail, but if anyone has trouble replicating, let me know.

screen.ActiveDatasheet.SubdatasheetHeight = 300

Works to make the height smaller, but you can't make it bigger then the original Height. It's interesting that you can get a subform into a datasheet form, but not into the detail section of a continuous form..

I used a different property.

In my opinion

We all have opinions, as Doc says, we can not know for certain how things are setup from within MS Access' guts. The app exposes some of its features through COM and if we debug and see what's inside, we can do quite a bit. Now, we all have different reasons for hacking it, you might think there's no point in exposing bugs, miscoded or misprotected components, but I know some folks who would be interested in knowing these vulnerabilities.

 

[The_Doc_Man]

Now, we all have different reasons for hacking it, you might think there's no point in exposing bugs, miscoded or misprotected components, but I know some folks who would be interested in knowing these vulnerabilities.

Which is precisely why the End User License Agreement strictly prohibits reverse engineering.

For those in doubt, for Win10, do Start >> Settings >> System >> About >> Software License Agreement (it is at the bottom), then find topic 2, part c, paragraph (vi)

For other versions of Windows, you're on your own to find the corresponding part of the EULA.

 

[Edgar_]

Which is precisely why the End User License Agreement strictly prohibits reverse engineering.

We are all criminals then, Doc. For clicking debug after we get an error

 

[MsAccessNL]

I made a video to show how to do change row height for the subform and add some events to the main form.

I don't have a microphone to explain what is going on in detail, but if anyone has trouble replicating, let me know.


I used a different property.


We all have opinions, as Doc says, we can not know for certain how things are setup from within MS Access' guts. The app exposes some of its features through COM and if we debug and see what's inside, we can do quite a bit. Now, we all have different reasons for hacking it, you might think there's no point in exposing bugs, miscoded or misprotected components, but I know some folks who would be interested in knowing these vulnerabilities.

Thank you Edgar, your time and effort, it’s very much appreciated! The only problem with your solution is that the rowheight of the subform/subdatsheet is now (also) larger. I was looking for a way to make only the subformcontrol larger. Like with SubdatasheetHeight, but that is only usefull to make the control smaller. Another interesting question is, how did they get the subformcontrol in there, between the rows?

 

[ebs17]

exposing bugs, miscoded or misprotected components

This is a formulated motivation and can be left as such. @MsAccessNL obviously has a different motivation.

But it's something different if you want to consciously bypass Access forms or, as a replacement, MS Forms and use open tables (table views) and program something like that for an application. That has nothing to do with the intended security.
I know that a user or other outsider should never have anything to do directly with the database tables. Obvious foregrounding is the opposite of recommended concealment. Anyone who climbs the rope should be aware of the risk of falling quickly.

Back to the table again. This is created and managed in the database engine, here in the Microsoft Office XX.0 Database Engine. I can work with this table and juggle using SQL, DAO and/or ADODB. A plain text file (VBS) can contain and execute necessary code. If I know what I'm doing, I don't need an extra view.
Views and help for operation are then front-end functionalities and come a few levels later.

 

[MsAccessNL]

I made a video to show how to do change row height for the subform and add some events to the main form.

I don't have a microphone to explain what is going on in detail, but if anyone has trouble replicating, let me know.


I used a different property.


We all have opinions, as Doc says, we can not know for certain how things are setup from within MS Access' guts. The app exposes some of its features through COM and if we debug and see what's inside, we can do quite a bit. Now, we all have different reasons for hacking it, you might think there's no point in exposing bugs, miscoded or misprotected components, but I know some folks who would be interested in knowing these vulnerabilities.

Hello Edgar,

Good news here. I discovered how the linked datasheet has been made! In the picture you see to table in one datasheet who are not linked to each other and this is made in a form. This is not a table view!. The trick is, that they use the tabbed layout control for the subform/subdatasheet. If you make a form and make the controls layout tabbed, ad an empty layoutcell beneath the first control, set the sourceObject to any table you want, set the view of the form to datasheet and Voila! You have the subdatasheet view. The table don't have to be linked. It's just an optical trick.

It brings a new perspective on programming. I am excited to explore this further!!

I am realy proud on this one.

 

[MsAccessNL]

WOW SUBFORM IN A DATASHEET FORM NEVER SEEN BEFORE!!!! (I think...)

 

[isladogs]

I agree that's something I've not seen before but I'm unable to see any practical use for the idea.

Also I assume that if you expand the subdatasheet for every record, it would show the subform for every record.
Whether that's lots of distinct copies of the subform or mutiple instances of the same subform, I'm not sure
Either way, that would be utterly confusing to end users and a drain of resources, potentially leading to a crash.

 

[The_Doc_Man]

We are all criminals then, Doc. For clicking debug after we get an error

Well, not really. We would be criminals if MSACCESS.EXE popped up a C++ or C# equivalent of the DEBUG button such that it exposed the inner code of the Access program and we then actually looked at it. What we see when we hit the Access DEBUG button is a user-developed app's code, which isn't covered by the EULA.

But recently Pat Hartman had threads about securing apps, which is therefore a layer related to this problem. Many of us would LIKE to be able to secure our apps and we have to rely on EULAs for OUR code since it is almost impossible to block people from examining content.