We have been using FB3 for over a year. I developed a generic FB3 project for doing SQL Server database builds. Called from the command line, variables specify the database name (among other things). Having one generic FB3 project is of course good because it means there is less FB projects to maintain compared to having one FB project per database.
This has been working well but I just upgraded to FB 4 and.... it appears that FB4 won't let us run more than one instance of a given project. I noticed that a project_name.lck file was generated while the project was running. This seems to block anyone else from running the generic project for other databases. I guess one nasty workaround would be to create a different version of the FB4 build project for every database we have... However, this would be very, very ugly to say the least.
Before I revert to FB3, can any FB4 experts out there tell me if there is a way to enable multiple instances of a particular FB 4 project to be run at the same time?
Thanks,
Clive R.
Hi Clive,
Unfortunately, this is because FB 4 uses a database format for the log file - which means it needs exclusive write access.
You can, however, run extra copies of a project from the command line under FBCMD with the /TL (temporary log file) flag. Unfortunately, this means that the project’s log output will not be available after the build ends.
Alternatively, a trick you might want to try is to use different “stub” projects for each instance which needs to run concurrently. Each stub can just use the “Include Project” action to include the main project, and either use the “Share Variable Namespace” option or specify individual variables to set. Because all of the log output goes to the parent (“stub”) project, you can run the child (“main”) project multiple times concurrently. You will need to go to the “stub” project in order to see the log output, however.
In your case, you might even be able to make a separate “stub” project for each different database, and have it set the relevant variables as part of the Include Project action instead of from the command line.
We are aware that this one-project-at-a-time limitation is something which can be frustrating, so we are looking into more satisfactory ways to get past it in the future.
Angus,
Thank you for the reply. Turning off the log output might be the way to go for now although we do depend on log output quite a bit. However, I can setup separate logged runs when problems need diagnosing.
I thought about the stub projects as well but it’s turns what is an automated/generic solution into a manual/specific one. We have it setup so that a new database can be included in the database by simply making a call to the main project with the new database name passed into it.
It’s good to hear that you guys are looking at fixing this issue. I’m really surprised it was designed into the product in the first place. I am a fan of FB3 but have found several issues with FB4 that kind of turn me off the product. First, the user interface is now cluttered - the FB3 one was simpler and just gave what info that was required, no more, no less. Second, in FB3, a sub-project’s output would be displayed in the main project’s output in a nested manner, whereas FB4 simply doesn’t seem to do this. I can see what task is running in the sub-project but, overall, it’s a retrograde step. Thirdly, this other retograde step where you can’t run a project more than once without turning off logging and so on. Just a suggstion… why don’t you guys go back to FB3 source and apply minimum changes to it as a FB5? If it ain’t broke… ? It’s a big concern for us because our build process is a critical function and we now see business risk coming from Final Builder upgrades where there was none before.
Best regards,
Clive
Hi Clive
FinalBuilder 3 had a similar issue with running multiple instances of the same project file, it was a case of first in best dressed when it came to the log file. The other instances would just write to a temporary log file (to enable the export log file action to work) and then delete the temporary log file when they exited. We had a number of customers raise this issue with us (what happened to the log for the other instances?) and so with FB4 we took the decision to raise an error if the log file was in use.
In a future release, we plan to introduce a log server (usage will be optional) which will allow FB’s logging to work in a client/server fashion and that will resolve the exclusive locking issue.
As for the UI changes in FB4, you can in fact make it behave just like FB3. In the FinalBuilder options dialog, switch to the FinalBuilder\General Options page, then click on the GUI Options page. Set the Build Summary to “Never Show Build Summary”, and set the Live Logging to “Enable Live Logging by default”, and make sure the “Switch to Live Loggging tab if live logging enabled” is checked. That will give you back the same behaviour as FB3.
I tested the Include FinalBuilder project action and the logging behaves the same as it did in FB3, or am I missing something?