Search results

I had the very same problem in the past and wrote on it here: Compiling an Access project with VB-Script

An Access add-in requires more configuration/installation and is prone to problems when run unattended. I would rather use a script to directly set all required properties. You could still use an add-in to create the XML configuration file, but the build process itself should run without an...

@Josef P. , thank you for your work and the posts here. I understand your scripts are customized for GitHub Workflows. Did you also evaluate how this approach can be transferred to Azure Pipelines?

If you combine the three queries into one using a UNION query, as @Gasman suggested, you will get the desired result. With ADO Recordsets it would also be possible to copy the records from multiple recordsets into one new recordset. However, this would be rather slow row-by-row operation. The...

If the suggested solution for timestamping actually ever worked (I strongly doubt it), it should still work regardless of where the certificate is stored. The new (2023) requirement for secure storage is not technically enforced. It is just an agreement by the certificate issuers industry...

It is possible for an organization to create email accounts with a 3rd-party provider and then the user (you) creating a personal Microsoft Account with that email address. But this is rather unusual. Normally, the organization's IT admins would register the domain as a Microsoft 365 Tenant...

Your above statements contradict each other. If the "problem" only exists with your account in yourOrganizationDomain, it is clearly not your private account, but an account set up by your organization for you.

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...