[CONNECT VBA] DatabaseExamples project missing COM References

Hi John,

Jon Summers said:

The project references a missing Microsoft ADO DLL.

Well, "a standard answer" is that it's caused by missing ADO (ActiveX data objects) library installation. But it's not the answer how to solve the issue.

I remember vaguely it was discussed already, but I was not able to find the thread. The problem is that there is no standalone installer to add 64bit ADO to your computer (I have not been able to find any such page) ... and I think to download individual ocx and dll files from different webs is not the best way.

Because the situation cannot be solved easily even by advanced users, I guess Bentley would change the example to use some another API that is available on Windows 10 by default. May Artur Goldsweer provide some insight?

With regards,

  Jan

Hi John,

Jon Summers said:

The project references a missing Microsoft ADO DLL.

Well, "a standard answer" is that it's caused by missing ADO (ActiveX data objects) library installation. But it's not the answer how to solve the issue.

I remember vaguely it was discussed already, but I was not able to find the thread. The problem is that there is no standalone installer to add 64bit ADO to your computer (I have not been able to find any such page) ... and I think to download individual ocx and dll files from different webs is not the best way.

Because the situation cannot be solved easily even by advanced users, I guess Bentley would change the example to use some another API that is available on Windows 10 by default. May Artur Goldsweer provide some insight?

With regards,

  Jan

Hi,

thanks for reporting this issue.
We have filed now a Defect # 1063499 to address this issue and will investigate further to look for possible workaround / fix.

Best regards,

Artur

Artur Goldsweer said:

We have filed now a Defect # 1063499

Here's the response received March 2021: Bentley Development has reviewed the Defect/Enhancement request you reported to our Support Team. After careful evaluation, it was d etermined that your request cannot be implemented at this time, because this functionality works as it was designed and intended. This issue will now been closed..

This functionality works as it was intended?  No: it doesn't work for the reasons I reported in my first post.   Jan's response is more helpful and explains the difficulty of implementing a solution.

The best result would be for Bentley to remove that VBA example from the MicroStation installation.

Hi John,

Welcome to my world!!!  I have had critical issues that affect our productivity and don't allow me to have the entire office update to Microstation.

1) Several months ago, I had a someone contact me to tell me that the problem was that I was using a non-standard naming convention.  When I showed him that Bentley was doing the same thing that I was, his response was "they are normal files, not cad files.  When I did some web research and pointed out "cad drafting standards" that matched my way of doing things, he said that there were not enough complaints to warrant getting this fixed.  When I pointed out conditions under the standard that he follows where this would not work, he ignored me and/or sent back the same response that I was not following proper cad file naming standards.  (P.S.  This issue was previously partially fixed, just not for the condition that I face every day.)

2) Since the original release of the Mstn CE beta version, I've been complaining about the behavior of the file-open dialog box.  That issue was recognized and corrected, except for my every day condition when the dialog box is opened and pointed to a file via VBA.  Today, I was informed that the defective behavior is WAD, even though they have recognized it as a defect.

3) I have a problem with SetAttachedNameDeferred.  When the command is given, the referenced file name is updated in the display.  Under certain conditions (which I encounter on a semi-daily basis), when the file is re-opened, the original reference file is attached, not the new one that was set by this command and displayed by Microstation.  Even though it has been recognized as a defect, I got a notice today saying that this is WAD.

Bentley is charging us a large annual fee for support.  They are also discontinuing support for the latest version of Microstation that still works properly for us.  When they don't want to spend the time or money to fix a REGRESSION, then they simply give us LIES and brush us aside.

How do we get this root problem fixed?  How do we get discounts for the defective product that Bentley is trying to get us to use?

--Thanks,
--Robert Arnold

It sounds as if they are clearing their queue by just filing everything as WAD...

MaryB said:

It sounds as if they are clearing their queue by just filing everything as WAD...

I think it's a bit unfair. You are right, sometimes it seems to be the way used by Bentley (but not only ;-)

On the other hand, when I return back to the original topic of this discussion, the discussed VBA example should be removed from MicroStation installation, or, alternatively, there should be a notice it will not work without (I guess) Access 64bit installed.

It's the illustration why VBA is a curse, not efficient tool today and why many companies removed VBA from their product (or kept it, but as unsupported option). Microsoft does not support VBA and because it was used primarily in 32bit era, 64bit versions of many libraries simply not exist (or, they are only part of bigger products).

The only solution is to forget VBA and to move e.g. to C# (or, VB.NET, but it's not developed actively anymore). It's what I think many user will have to anyway, when they will realize they are not able to mo migrate macros to CE, because old COM and OCX libraries, referenced by their macros, are not supported and do not exist in 64bit versions.

With regards,

   Jan

Hi Jan,

Microsoft Office 2019 (locally installed) comes with VBA, ie it is still being supported.  Overall, it did not take too much effort to upgrade my Microstation VBA to work with the 64-bit platform.  The main issue is that Bentley has some bugs with their end of implementing VBA.

In the professional programming community, BASIC, in general, is not first choice of programming languages.  There are languages that are designed with more abilities.  Also, there is a trend to make everything an on-line or on-phone app.  But, most of us are not in professional programming.  I've been programming in BASIC since the early 1980's, but that is not my profession.  I'm an engineer, doing structural design.  Computer IT, and Microstation setup/management is an auxiliary task.  Microstation programming is an auxiliary task to that auxiliary task.  VBA is a rapid development language that fits the bill.  As you said, VB.net is not developed anymore, and has the slow-down and complications of going through the dot-net interface.  That leaves VBA as about the best, and fairly powerful, programming / scripting language available to us little guys.

--Thanks,
--Robert Arnold

Hi Robert,

unfortunately, there are some errors, myths and misunderstanding in your text. Which does not mean I do not understand your attitude. It well demonstrates the difference between local perspective and needs and overall changes and historical limitations.

RobertArnold said:

Microsoft Office 2019 (locally installed) comes with VBA, ie it is still being supported.

It's maintained (in a meaning not removed from the product), but not really supported. Microsoft has not offered VBA license to external companies for about 10 years, the last new features were introduced in VBA 7 also 10 years ago. Even Microsoft did not migrated many own libraries to 64bits, or they are available in functionally limited form. And Microsoft itself recommend to use other tools to write applications for Office.

Of course there is the reason why VBA cannot be removed from Office: An amount of existing code. Microsoft has tried to introduced other tools (VSTO in the past, Office add-in model today), but they were not accepted widely enough (yet?) to allow to remove VBA.

Many other companies does it, including ESRI and Autodesk, who as far as I know quite long time ago announced "VBA removal" plans and now offered VBA separately only when the migration from this technology is not finished yet. There are many problems with VBA integration and the maintenance and support cost is high, so you will not find VBA actively supported in modern applications.

RobertArnold said:

The main issue is that Bentley has some bugs with their end of implementing VBA.

I disagree completely. It's true that VBA in CE is very buggy. It's not good, but can be (and should be) repaired by Bentley. But the fact that so many OCX, ActiveX and other libraries, used by V8i macros, do not exist in 64bit version and will never do, cannot be solved by "just fixing bugs". Plus, some other libraries are hard to be installed and maintained, as clear from e.g. Access support: 32bit can be installed, because separate installer ODBC/OLEDB exists. Simple to do and maintain. I remember when we tried to solve it some time ago, the only solution for 64bit was to install (and license) complete Office.

RobertArnold said:

In the professional programming community, BASIC, in general, is not first choice of programming languages.

I did not write anything about relationship of professional community to BASIC dialects. And you are not right, many professional programmers have used VB or VBA as a tool to evaluate concepts and ideas.

RobertArnold said:

But, most of us are not in professional programming.  I've been programming in BASIC since the early 1980's, but that is not my profession.

It looks like based on situation before 20 years, when BASIC was undoubtedly the tool for not professional developers and languages like C, FORTRAN or Java were for the professional one. But it was not true anymore even before 10 years. There are hundreds (maybe over a thousand?) of languages available and many from them were chosen by not professional developers as the best tool to solve their problems. BASIC dialects are abandoned mostly and languages like Python, LISP, Julia, R, also JavaScript and many others are used by people without any formal software engineering knowledge.

RobertArnold said:

VBA is a rapid development language that fits the bill.

It is, and in fact it was enormously successful, but today it's more and more complicated to maintain it, plus in 64bit world it lost completely one from the biggest advantages: a number of available libraries, that can be easily referenced. Plus, IT people like it less and less because of security issues, because when ActiveX / COM concepts were investigated and implemented, not many people were able to even think about possible threats (plus, Microsoft at this time always wanted to promote own ideas only, so they did a lot of mistakes, some from them was not able to fix, because too deep in design).

But other languages has taken VBA role step by step. What I see is that Office and MicroStation are the only still so much based on VBA. All other software I see in my customer, typically offer Python, plus some other alternatives sometimes.

RobertArnold said:

As you said, VB.net is not developed anymore

Yes, but it's crucial to understand that "VBA not developed" means it has not received anything new for 10 years, whereas "VB.NET not developed" means that it was actively migrated to the latest NET.CORE 5 last year, including very rich support of old and new technologies and API, including the modern compiler. "Not developed" means here it will not probably receive new features (whereas C# receives new feature with every NT version).

RobertArnold said:

and has the slow-down and complications of going through the dot-net interface. 

Where you hear it? Do you have any proof?

VB.NET itself is not slow, it provides similar speed to C#. When used on top of Interop, there is worse performance (plus all bugs existing in VBA), but still substantially faster than VBA. And using "similar to VBA" syntax, also new and very fast NET API can be used (of course step by step, because different from Interop object model).

RobertArnold said:

That leaves VBA as about the best, and fairly powerful, programming / scripting language available to us little guys.

Yes for you, probably for people knowing VBA from the past, but only in context of MicroStation. Elsewhere VBA is forgotten and abandoned more and more.

But it's not the problem whether VBA is great language for MicroStation users ... because it is. The problem is somewhere else, out of reach of users (and partially also of Bentley): The ecosystem is rusted, erodes and becomes obsolete, even when nobody can argue that it does not serve its task well.

Unfortunately, I do not know about any long-term vision how to prepare a leaving of this slowly sinking technology, allowing users to migrate smoothly to something else.

With regards,

  Jan

Hi Jan,

Thank you for your reply.  My world is Microstation and Microsoft Excel.  Also, I mostly just use the default references to VBA, Microstation Library, and Microsoft Forms, so the lack of API / ActiveX / library support doesn't affect me much.  So in my little world, VBA is still seems like the way to go...

--Thanks,
--Robert