Printable Version of Topic

Click here to view this topic in its original format

UtterAccess Forums _ Tool bars, Menu bars + Ribbon _ Access 2016 Create Query Mouseover Text

Posted by: Rikenbark Oct 17 2019, 05:42 AM

I am migrating from a Windows 7 box with Access 2010 to a Windows 10 box running Access 2016.
I see that the text when hovering the mouse over a query that creates a table (in the Access Objects frame at left of the window) has changed from just showing the table name to both the query name and the table name joined together.
e.g for a query called "create_test_table_2" that creates table "test_table_2" the mouseover text is "create_test_table_2test_table_2" with no delimiter between query and table names.
Makes it tricky to read etc.

Does anyone know of a way to control this please? Thank you.

Posted by: GroverParkGeorge Oct 17 2019, 07:34 AM

Welcome to UtterAccess.

Probably because I almost never create and save MakeTable queries, I've never noticed that tool tip property before.

I don't think I've ever seen a reference to a setting for it either.

Time to do a little more research.

Posted by: GroverParkGeorge Oct 17 2019, 07:46 AM

On a related note, I want to talk a bit about the philosophy behind using make table queries versus append queries.

Most of the time, the only reasons we'd want to create a table using a query would be when initially designing and setting up a new Access Relational Database Application or when creating a temporary work table for a complex process.

In the first instance, there are times when part of that design and development call for creating things like Lookup tables from a group of values in an existing datasource, or perhaps trying out some design ideas. In a real, working Access Relational Database Application, creating new tables would be an exceedingly rare event except for the case of a temporary work table needed, for example, to provide aggregated records for a report.

In the second instance, it is usually (not always, but nearly always) better to create and store a "permanent" temporary work table. That allows you to define datatypes for the fields in it and apply other properties, such as validation rules on fields in it. Instead of deleting and re-creating the temporary work table, the method is to delete existing records from it and then use an append query to put the new set of records into it as need. This is sometimes referred to as "Flush and Refill".

For those reasons, it's rather rare to see a saved Make Table query, IMO, and this little quirk of the tool tip for them probably hasn't been noticed by many people.

Posted by: Rikenbark Oct 17 2019, 08:22 AM

Thanks George.

Background ... before getting into the merits of how things work or are structured.

Our Access databases are a suite of queries for collating and crunching high record-count technical data sources to produce small data warehouses for estate and asset management.
There is no user engagement via forms or reports, and all tables/content are recreated fully every night as part of a logic layer before being eventually transferred to a publication layer.
Hence the queries are saved and are run sequentially from a form on an overnight schedule.

It was a simple solution to a set of problems encountered the best part of 20 years ago.

Migration of processing from Access to SQL Server is on the cards, when I get the time to do that (I am a spof).

It may be that Microsplodge have stuck again, changing the design of a product to "improve" it without considering they may be creating unwanted niggles for users.

Posted by: GroverParkGeorge Oct 17 2019, 08:30 AM

I did say "rare" thumbup.gif

Actually, my last "coporate" job was in a reporting environment where we did a lot of the same kind of aggregation you describe. We used the "Flush and Refill" procedure, not the "Kill and Replace" approach, for the reasons I mentioned. That said, as long as the process works as you need it to work, it's all good. The main thing there is that regular Compact & Repair operations are needed to minimize database bloat.

On the scale of problems that can beset an Access Relational Database Application, this one seems closer to the "meh" end. If it impedes your work flow, it is undesirable. I'm hoping to get feedback from someone in the know soon.

Posted by: GroverParkGeorge Oct 17 2019, 08:36 AM

Interestingly, I just opened an old VM with Access 2010 on it.

This is on Windows 10 and Access 2010.

Posted by: Rikenbark Oct 17 2019, 08:49 AM

Hmm, so looks to be an Access 2016 thing rather than a Win10 thing.
Thanks again George

Posted by: GroverParkGeorge Oct 17 2019, 09:06 AM

I would say that, if you DID NOT see the table name in the tool tip on Win 7, A2010, but I DO see the table name in the tool tip on Win 10, A2010, it's a Win 7/Win 10 difference, not an Access difference.

Posted by: isladogs Oct 17 2019, 12:41 PM

I was intrigued so I checked using a Win 7 VM and A2010.
The same effect occurred for both make table and append queries as is the case in Win10

So this 'possibly useful' feature has been around for years without many of us noticing! sarcasm.gif

Posted by: GroverParkGeorge Oct 17 2019, 01:39 PM

I got some feedback from the MS Access team. They're going to look into this given that the two names are just mashed up with no differentiation. We'll see how it turns out.

Thanks for bringing it to everyone's attention.

Posted by: Rikenbark Oct 28 2019, 05:09 AM

Thank you. Greatly appreciated.