Different versions of DOA

[Clayton Arends]

Allround Automations,

I just upgraded from C++ Builder 4 to C++ Builder 5 and was moderately disturbed to find out that the new version of DOA.BPL was not compatible with already existing C++ Builder 4 applications.

I wouldn't care if the versions wouldn't work with each other if the BPL files had different names (DOA40.BPL, DOA50.BPL) but I have applications that share the DOA package and now will have to either upgrade ALL applications to C++Builder 5 or find a way to rename your newest package to DOA50 myself.

I love the product I just think a little foresight would have been nice for the naming convention. Or, like COM objects, backward compatibility were possible (though I think we have Borland/Inprise to blame for that problem).

Am I wrong about this? Is the Builder 5 version of the package compatible with Builder 4 applications? Please let me know. I attempted to run an application and it was unable to find a necessary method or object during start up. "...is linked to missing export DOA.BPLOracle@TOracleSession@CheckConnection$qqr4bool"

Thanks,
Clayton

 

[Marco Kalter]

You're the first to run into problems with this. We have all C++Builder versions installed on one PC and they don't conflict in any way. Exactly when and how do you get a conflict with the C++Builder 4 and 5 DOA.BPL packages?

------------------
Marco Kalter
Allround Automations

 

[Clayton Arends]

Only one? Hmmm... should that make me feel good or bad?

I mentioned the error message I received in the last post. If it wasn't clear when I'm getting the message let me mention it again. I'm getting it when launching my application. The part during execution where all statically bound DLLs and BPLs are being loaded by the OS. It's not getting to any of my code yet.

All I did was overwrite the DOA.BPL (Builder 4, DOA version 3.3.2.0) with the new file (Builder 5, DOA version 3.3.2.0) and ran my Builder 4 application. It errored giving me the message I mentioned in the last post.

By the way, I was successful in installing DOA as DOA50. That setup procedure you have is wonderful for last minute or late changes. I will be proceeding forward in this direction unless (until) you can find a suitable fix or we can figure out if I did something wrong.

Thanks again,
- Clayton

 

[Clayton Arends]

I just noticed that you have a version 3.3.3 available. I will download and see if that solves the problem.

- Clayton

 

[Clayton Arends]

Downloaded and installed both the Builder 4 and 5 versions of DOA v3.3.3. One at a time I copied the DOA.BPL file into my application's directory and overwrote the existing DOA.BPL file. Builder 4 with DOA v.3.3.3 ran just fine. Builder 5 with DOA v.3.3.3 gave the exact error message that I mentioned before ... "The EVIFFDB.DLL file is linked to missing export DOA.BPLOracle@TOracleSession@CheckConnection$qqr4bool."

I then made a small simple application in Builder 4 that just has a form and a TOracleSession component on it ... no code. I built it with the "vcl40;vcldb40;vclx40;vcldbx40;DOA" packages and ran it. No problem with the Builder 4 DOA package. I get a plain EAccessViolation if I run with the Builder 5 DOA package at startup.

Am I supposed to include another package? If you can, please give me an example application that you know works in your environment and I'll run it in mine alternating between the DOA packages.

Thanks,
- Clayton

 

[Marco Kalter]

I can only reproduce this problem if I remove the DOA.BPL file from the application directory. Otherwise it works just fine. I have C++Builder 4 and 5 installed and can run C++Builder 4 and 5 applications simultaneously with DOA.BPL as runtime package. Both applications have the package in their respective directories.

What happens if you remove the DOA package from the runtime packages list in C++Builder 5? Does this fix the access violation?

------------------
Marco Kalter
Allround Automations

 

[Clayton Arends]

My Builder 5 applications are fine. From reading your messages again I think you have missed the problem that I am referring to. I am not having a problem with DOA when running Builder 4 and Builder 5 (in fact I run both IDE's at the same time). I am talking about applications that I CREATED using Builder 4. The access violation occurs when I launch an already existing Builder 4 application that was built using the DOA package. Again, all I'm doing is overwriting the existing DOA.BPL file (Builder 4 version) with the new Builder 5 DOA.BPL file.

I am sure the problem wouldn't happen if I built my Builder 4 applications without the DOA package (since the code would be internal to the EXE) but that wouldn't solve my problem which is to not rebuild and redistribute the applications.

Perhaps it is my fault for installing the DOA.BPL file in to Windows\System and expecting that all future versions of DOA.BPL would be backward compatible. I should have kept the BPL in my local application's directory and for each new application I write put the DOA.BPL file in the new application's directory. Redundant but at least I have versioning control.

The reason I did it the way I did is because I have several applications that are installed into seperate directories and I wanted them to share the VCL packages ... including DOA.

I am going to continue with the DOA50 route. That at least works and allows my older BCB4 built applications to run. Plus, I can have both in the Windows\System directory.

 

[Clayton Arends]

In fact, after reading the entire thread again, now I am POSITIVE you aren't on the same page as me. I figured from your original response that you knew I was having a problem with applications I created in BCB4 and not the IDE itself. So, I took shortcuts in explaining my problem the second time around. Everytime I speak of "my Builder 4 application" this really means "my Builder 4 compiled application." The same goes for Builder 5. I never had a problem with the IDE for either BCB4 or BCB5.

Please re-read the thread using this new perspective (my Builder 4 built applications having problems, not my BCB4 IDE).

 

[Marco Kalter]

No, we were on the same page. Like I said in my previous message, for the C++Builder 4 & 5 applications the DOA.BPL file resides in the application directory and both run fine. I can run them from within the C++Builder IDE and standalone. I just haven't installed anything into the windows\system directory, that's all. If you do the same (copy DOA.BPL into the application directory and remove them from the system directory), you should be okay too.

We will look into the possibility to include the DOA version number and Delphi/C++Builder version number into the package filename for the next release (e.g. DOA34C5.BPL).

------------------
Marco Kalter
Allround Automations

 

[Clayton Arends]

Same page, gotcha. I confused myself when reading your posts again. Sorry.

Okay, so as it stands, the DOA.BPL should be placed in a local directory and that's the only method you've actually tested. The product is thought of as a per-application enhancement. No mix-matching of Builder4 and Builder5 applications in that directory is allowed. And, no sharing of the DOA.BPL package is possible for executables (part of the same application) that exist in seperate directories.

Thank you for chatting with me on this subject. I have confirmed that I am not crazy and that my system is, in fact, set up correctly. I have just been bit by a Borland package problem and will, still, be moving forward on the path where I've renamed your package to DOA50.BPL.

I would like to suggest that you not put the version number of your package in the name (unless DOA34 is really different than DOA35). Otherwise, you can't just upgrade an existing application by overwriting the old BPL. You should however use the Borland package naming scheme which is to just show the version of the compiler used. DOA40, DOA50, and soon (if ever) DOA60. The version of your package will be in the "Version Info" already.

I don't know if your package crosses the Delphi/Builder boundary. If not, then consider using DOAxxD and DOAxxB to distinguish. Just my suggestions.

Using the current naming standard (DOA), if your components become popular enough that everyone is using them, and any TWO of those applications use the Windows\System directory to store your package ... well, you can see where I'm heading with this.

Once again, thanks for a great product and thanks for talking this over with me.

- Clayton