Search results

What about: =String([YourLineSpaceCount];Chr(10)) & " " as ControlSource of Textbox with CanGrow=True

Maybe don't call the MsgBox function then?

@honorkat, the file in the Visitors.zip you uploaded is an ACCDE file that was just renamed to ACCDB. The VBA code in file cannot be edited nor viewed. Find the corresponding ACCDB file and many problems you encountered will resolve themselves. The code incompatible with 64bit is most likely in...

Press and hold the [SHIFT] key and then open the access file. Unless explicitly disabled, this prevents startup code from running and will allow you to open the file.

Are there multiple projects (top level nodes) visible in Project Explorer? If yes, maybe you selected the project representing an add-in or library database? These are not editable by design. With hindsight, my suggestion of using Debug->Compile wasn't that good after all. This will work if...

In the VBA environment use menu "Debug" -> "Compile ...". Then it should show you the first problematic code right away.

I have no idea what that means and what you are asking exactly. You can add a "Windows Media Player" ActiveX-Control to a form and control the player's behavior with VBA. There are promising results for a simple online search on the matter...

Changing the RowSource will automatically cause the ComboBox to requery. So, you will increase performance a lot by just leaving out the explicit Requery.

Long shot: Before executing your script, check whether there is a hanging instance of MsAccess.exe in Task Manager. Does the script fail to open the database when there is a hanging instance and succeeds when there is none?

Viewing your project as an object of curiosity, I would be impressed by this reply. However, viewing it as a production environment solution to a real business problem, I would strongly advise any customer to stay away from that product. This is not about you or your project. It is about the...

It creates an ADODB.Connection to the current ACCDB database, which in turn then uses an ODBC connection to the SQL Server backend. This works to some extent, but I would not do it this way because you forgo the advantages of a direct ADO connection to the backend and it also might cause some...

The (VBA)project name is independent of the file name, which is a huge benefit when your file name is something like "Diabetes_Backup_20241010_RestoredToRecoverLostForms_20241014.accdb"

That's perfectly correct! And "compile to an mde" is the explanation why compiler constants, which are applied during that process, don't have an effect after the compilation process. I only nitpicked on this because in the context of this thread it's particularly important to distinguish...

There is a subtle error in these introductory sentences. Compiler constants will not resolve bitness at run time but at compile time. When distributing an mdB/accdB, compilation might happen immediately before execution, but they should still be viewed as different subsequent processes...

You could do that but you might not even need to. Just name the 32bit and 64bit DSN exactly the same and and your application will work in both bitnesses without requiring a single line of code dependent on the bitness. Even on a single computer 32bit and 64bit ODBC drivers and DSNs can coexist...

I didn't ask any question. If you consistently plan for your project to grow to an indefinite size, you can never start it because it might eventually grow so large that all computers in this universe combined will be unable to handle it.

As mentioned, I didn't use that driver myself. The vendor lists 32bit and 64bit compatibility on the features list. So, I assume it is a bundle supporting both. "xBase" is a summary term for multiple database applications using a dBase file format. Visual FoxPro support is explicitly listed...

If you seriously anticipate your project growing to more than ~5000 modules and to more than 32768 objects in total, the best approach should be glaringly clear: Do not use Microsoft Access! And, even though you do not want to hear this, I worked on multiple very large projects in Microsoft...

Thank you very much for this important comment. I thought this was obvious and thus didn't mention it. BTW: *All* ODBC drivers are bit specific by their very nature as native DLLs. Some driver vendors obscure this fact by bundling the 32bit and 64bit edition of their drivers in one generic setup...

I can reproduce this issue; not sure what is causing it. Workaround: Run CMD as Administrator Then open the ODBC Admin tool from the command line: %windir%\system32\odbcad32.exe