Search results

Yes. https://learn.microsoft.com/en-us/office/client-developer/access/desktop-database-reference/begintrans-committrans-and-rollbacktrans-methods-ado

Unless the query or tables in question are also used by another open form at the same time, it should work to set the Connect property of the linked tables to the other remote database. You could also (re)write the query SQL to contain a direct reference to the remote table using the IN syntax...

In a (sub)form's Open event the Recordsource was not touched in any way yet. I suggest you verify your statement about the sequence of events. - You might be in for a counter-intuitive surprise.

What exactly did you try and why exactly did it fail? - It should work, if done right.

But that's the point, isn't it? The main problem with the printing dialog, at least for me, is that it allows the user to intentionally or accidentally cancel the generation of the PDF. Hiding the dialog primarily prevents the user from cancelling the process. This is a feature, not a bug!

What timer interval did you set? Maybe it would work less invasively with a longer interval? Did you try to add DoEvents to the TimeProc to enable Access to process other operations while the time is running? I like your approach very much. It would be better to identify the dialog window by...

Are they? The process of generating a PDF from an Access report is a pretty specific operation. I doubt there is a Windows dialog that shows up for this without any control from within Access. (I mean Access from Microsoft's perspective, not ours.)

Thank you, that's indeed interesting. It's quite peculiar that there are many reports about financial software like DATEV and SFirm being affected, but not much else. I would have expected a much wider variety of reports considering that the problem should affect many (all?) ODBC drivers.

The solutions are either don't use it or use a driver fully supporting it. - I don't think this is applicable here, as it is the very same driver in both scenarios.

In absence of any better idea, I would recommend to turn on ODBC Trace and review the generated log file to find out whether the problem arises because Access submits the date in a different format or whether the ODBC driver interprets an unchanged date format differently.

Will not change the situation. The problem is that only functions natively implemented in the JET/ACE-Engine are available in queries from external applications (Excel in this case). Any function in an external library or written in VBA cannot be "seen" by the query engine when not run in Access...

You are enclosing some of the references to A.Something in text delimiters ('). These terms will be treated as literals and not as references to table columns. Only discrete text and date literals should be enclosed in delimiters.

That often does not help. If a column's type is automatically detected and then there is data in a row beyond those read for auto-detection that does not match the detected type, a type conversion error will occur just while Access/ACE is reading the file for import. I would probably link to...

What do you want to do? In most cases the limited uniqueness of the EntryId is enough. If it is just about uniqueness per se, you can also store the EntryId of the information store containing the contact. If you need to track items which may be moved across different information stores, you can...

Review the EntryId property of Outlook contacts.

Which Update Channel are you on? I'm not sure whether Monaco arrived in the semi-annual channels yet.

Not sure what relevance that does bear. It appears, it is possible to use RegExps to only reject links to other sites. Here is a thread in the Xenforo community showing examples: https://xenforo.com/community/threads/spam-phrases-to-detect-external-links-moderate.199113/

The first line looks like a Regular Expression to me. If this is correct, it should be possible to rewrite the "*//*" line to something that does not match links back to this site but every other occurrence of "//".

I would guess, (un)loading a COM add-in will trigger Access to reload/reprocess the ribbon XML. - If this is true, the behavior is more or less logical. The only potentially surprising "feature" is that the ribbon XML of the current database is (re)processed last. With startFromScratch="true"...

I think, @Josef P. was asking whether you hide ribbon tabs while you are developing the application. If your approach to hiding the ribbons tabs is "Hide everything, then show what the current user has permission for.", then it appears likely that you yourself are hiding the missing VCS tab.