# Persistent Variables
**URL:** https://www.finalbuilder.com/forums/t/persistent-variables/2748
**Category:** Bugs
**Created:** [January 5, 2007, 7:35am UTC](https://www.finalbuilder.com/forums/t/persistent-variables/2748 "2007-01-05T07:35:34Z")
**Posts on this page:** 19
**Page:** 1
### Author:  [@wasowerby](https://www.finalbuilder.com/forums/u/wasowerby)
#### Post date: [January 5, 2007, 7:35am UTC](https://www.finalbuilder.com/forums/t/persistent-variables/2748/1 "2007-01-05T07:35:34Z")
I have a Persistent project variable with no default value. If I run the project in the console, the variable persists ok through subsequent runs. However, if I run the project via the command line (using an Include action), the variable does not persist - whether it is initially set in the Console or the command line build. Is this a bug or am I doing something wrong?Using FB 5.0.0.84.
---
### Author:  [@tate](https://www.finalbuilder.com/forums/u/tate)
#### Post date: [January 9, 2007, 1:39am UTC](https://www.finalbuilder.com/forums/t/persistent-variables/2748/2 "2007-01-09T01:39:05Z")
Hi Andrew,
This bug should be already fixed, please try this build:
[https://www.finalbuilder.com/downloads/finalbuilder/500/FB500\_93.exe](https://www.finalbuilder.com/downloads/finalbuilder/500/FB500_93.exe)
cheers,
tate.
---
### Author:  [@deleted\_user](https://www.finalbuilder.com/forums/u/deleted_user)
#### Post date: [January 22, 2008, 10:10am UTC](https://www.finalbuilder.com/forums/t/persistent-variables/2748/3 "2008-01-22T10:10:41Z")
I think I'm experiencing this same problem, however I'm running version 5.5.0.518.
Is it reasonable to assume that my build should already contain this fix?
---
### Author:  [@angus](https://www.finalbuilder.com/forums/u/angus)
#### Post date: [January 22, 2008, 11:50am UTC](https://www.finalbuilder.com/forums/t/persistent-variables/2748/4 "2008-01-22T11:50:02Z")
Hi Zack,
That build should contain the fix for the bug described above. Are you seeing the exact same behaviour? Is it possible for you to outline it again for us, please, because the original post is a little confusing about the specifics.
Regards,
Angus
---
### Author:  [@deleted\_user](https://www.finalbuilder.com/forums/u/deleted_user)
#### Post date: [January 23, 2008, 1:49am UTC](https://www.finalbuilder.com/forums/t/persistent-variables/2748/5 "2008-01-23T01:49:01Z")
I think its pretty close the behavior described above but I’ll redefine the problem the best I can.
We’re running [CruiseControl.NET](http://CruiseControl.NET) which invokes our FinalBuilder projects. The Projects have a persistent variable defined that increments every time the build is run. For some reason, this variable is getting either randomly or is failing to increment. Just to give you a little more background, we were running our source control out of VSS for quite a while with this setup and experiencing no issues. A few weeks ago we switched to Fortress (aka Vault) and that seems to be when this problem started to show up. We’re also using Visual Studio 2008 for some of our builds, and these appear to be the most problematic. I’m not sure if VS 2008 support is officially out yet, we obtained a build of FinalBuilder that supported it via these forums.
Let me know if there’s any more info I can provide such as logs, sample projects files, etc.
Thanks!
---
### Author:  [@angus](https://www.finalbuilder.com/forums/u/angus)
#### Post date: [January 23, 2008, 2:40am UTC](https://www.finalbuilder.com/forums/t/persistent-variables/2748/6 "2008-01-23T02:40:12Z")
Hi Zack,
Thanks for the update. 518 is the current official build with 2008 support.
Is there any chance you have the .fbv file checked into source control? That file is where the persistent variables are stored, and if it’s checked in (ie Read Only) then you won’t see any changes saved to it (for obvious reasons.)
If you’re using the built-in SCC integration there is an option called “Keep auxillary files checked out” which will keep them in source control, but keep them checked out after each checkin so they’re always writeable.
Hth.
Regards,
Angus
---
### Author:  [@deleted\_user](https://www.finalbuilder.com/forums/u/deleted_user)
#### Post date: [January 23, 2008, 2:48am UTC](https://www.finalbuilder.com/forums/t/persistent-variables/2748/7 "2008-01-23T02:48:16Z")
No we don’t have the files in source control and I’m fairly certain the fbv file is writeable.
Would it be helpful if I emailed you a sample project?
---
### Author:  [@stevage](https://www.finalbuilder.com/forums/u/stevage)
#### Post date: [January 24, 2008, 3:54am UTC](https://www.finalbuilder.com/forums/t/persistent-variables/2748/8 "2008-01-24T03:54:07Z")
I don’t know if this will help you, but I’m pretty wary of persistent variables in general if the information they contain is important. I lost all the values of my persistent variables once, either due to a FB bug, a mistake on my part or some freak event. In general, I find it better to simply store the variables’ values in a .ini file, and load/save that at the appropriate times - you can load all the variables in just one action. If you version control that file, your chances of losing important values are very slim.
And it makes you feel good to have so much control over how and when the variables get populated with values 🙂
Steve
---
### Author:  [@deleted\_user](https://www.finalbuilder.com/forums/u/deleted_user)
#### Post date: [January 24, 2008, 4:01am UTC](https://www.finalbuilder.com/forums/t/persistent-variables/2748/9 "2008-01-24T04:01:05Z")
I thought ini files were supposed to be “read-only”, like a config file. Seems that if persistent values are not truly persistent, or are just persistent when they feel like it, that would be a bug IMO.
The value we’re incrementing in our case is the build number, so its not really something you’d want version controlled, but it is important that its incremented every build and that its saved between builds.
I guess what I’m saying is that if I have to go through some hacky work-around to persist a value when there’s already a prominent feature advertising that it handles all of that for me, I’m thinking that the feature should be fixed.
Thanks
Zack
---
### Author:  [@angus](https://www.finalbuilder.com/forums/u/angus)
#### Post date: [January 24, 2008, 6:54am UTC](https://www.finalbuilder.com/forums/t/persistent-variables/2748/10 "2008-01-24T06:54:04Z")
Hi Zack,
Thanks for your patience with this. You are, of course, correct that persistent variables should work "as advertised."
At the moment, I can confirm there is a bug with persistent variables which have defaults set - the variables are being reset to the default on each build, regardless of the persistent setting. This happens in both the IDE and FBCMD.
So as a temporary workaround, if the variables have default values set then removing them will fix the problem.
We should have a test build with a permanent fix out very soon.
Regards,
Angus
PS FYI, Ini files are designed for reading and writing (the Windows Ini file APIs work for reading and writing.)
---
### Author:  [@angus](https://www.finalbuilder.com/forums/u/angus)
#### Post date: [January 24, 2008, 7:01am UTC](https://www.finalbuilder.com/forums/t/persistent-variables/2748/11 "2008-01-24T07:01:09Z")
Zack,
If this isn't the bug you're seeing, could you please email us your project file (to support at finalbuilder dot com.)?
Thanks.
- Angus
---
### Author:  [@deleted\_user](https://www.finalbuilder.com/forums/u/deleted_user)
#### Post date: [January 24, 2008, 7:22am UTC](https://www.finalbuilder.com/forums/t/persistent-variables/2748/12 "2008-01-24T07:22:27Z")
Thanks for the tip Angus, I’ll give’er a go tomorrow and report back.
---
### Author:  [@deleted\_user](https://www.finalbuilder.com/forums/u/deleted_user)
#### Post date: [January 28, 2008, 5:17am UTC](https://www.finalbuilder.com/forums/t/persistent-variables/2748/13 "2008-01-28T05:17:23Z")
I think I finally tracked down the issue. First, a little background.
We have 2 builds running, one for Dev and one for QA. When each of them runs they create a label on the source and then pull from that label. The problem was that the QA build was labeling the same as the Dev build, thereby attempting to create duplicate labels and subsequently failing the build. I think that was causing the persistent variables to not be written to the fbv file.
Thanks for the help, apologies for any confusion I may have caused.
---
### Author:  [@angus](https://www.finalbuilder.com/forums/u/angus)
#### Post date: [January 29, 2008, 11:08am UTC](https://www.finalbuilder.com/forums/t/persistent-variables/2748/14 "2008-01-29T11:08:23Z")
Thanks Zack. Glad to hear you got it working. We turned up a bug anyhow, so something positive will come out of your bug report. :).
---
### Author:  [@angus](https://www.finalbuilder.com/forums/u/angus)
#### Post date: [January 29, 2008, 11:53am UTC](https://www.finalbuilder.com/forums/t/persistent-variables/2748/15 "2008-01-29T11:53:45Z")
Hi Zack,
Actually, I can't reproduce that bug at all any more - I think it must have been user error on my part the first time.
Regards,
Angus
---
### Author:  [@deleted\_user](https://www.finalbuilder.com/forums/u/deleted_user)
#### Post date: [April 17, 2008, 4:15am UTC](https://www.finalbuilder.com/forums/t/persistent-variables/2748/16 "2008-04-17T04:15:22Z")
Hi, sorry to reopen this long closed thread, but I work with Zack and a similar flavor of this issue is cropping up again. While he figured out what was going on there, now what I’m running into is this:
Running [CruiseControl.NET](http://CruiseControl.NET) to invoke the FB projects works fine, the build number (persistant variable) increases as designed. But then if I need to update the project, once I open the FBV file up and save it, the variable resets. I know if we remove the default value, this will correct itself, but then the value goes back to 1. The build number is being used as a label in Fortress (aka Vault) and when the project builds, it errors out that the “label already exists”, because the variable has dropped back to either 1 or the default value + 1 depending on if there’s a default value or not.
Our workaround has been to look up what the highest label number is when we need to edit a project and increase the default value to that, but should FB be losing the saved variable increment just by opening the project in the first place?
Hope that makes sense. ![]( "Smile")
Thanks!
---
### Author:  [@angus](https://www.finalbuilder.com/forums/u/angus)
#### Post date: [April 21, 2008, 2:02am UTC](https://www.finalbuilder.com/forums/t/persistent-variables/2748/17 "2008-04-21T02:02:16Z")
Hi Andy,
The variable definitely should not be resetting as a result of just opening and saving the project. Is the .FBV file checked into version control? Under this circumstance it’s possible that the local FBV is being overwritten with an older file from version control. Unfortunately the SCC integration only works from the IDE (not FBCMD) so it’s not possible to check the FBV file in automatically when running from [CC.NET](http://CC.NET).
One alternative to using persistent variables is to save the build number to a separate INI file (or similar) using the INI File actions. You can then check that file into source control and have it checked out and checked in automatically as part of your build process. That means that local copies of the FBV file will never interfere with the global build number. Please let me know if you’d like more information on how to achieve this. (You’ll also need to tell [CC.NET](http://CC.NET) to ignore changes to that file when triggering builds.)
If the FBV file is not checked in to version control, then it sounds like you’ve found a bug. What version of FB are you using? Do you have any other options (apart from “Is Persistent”) enabled on that variable?
Regards,
Angus
---
### Author:  [@deleted\_user](https://www.finalbuilder.com/forums/u/deleted_user)
#### Post date: [April 22, 2008, 3:55am UTC](https://www.finalbuilder.com/forums/t/persistent-variables/2748/18 "2008-04-22T03:55:19Z")
We are not checking the FBV into source control, or the INI file. Using version 5.5.0.627 at the moment.
Options checked on “Builditeration” are Make Available as Environment Variable and Persistent.
Another thing I’ve noticed today is that if I have the project open, it defaults back to the default variable, no matter how many times the project has been run through [CC.NET](http://CC.NET)…and if I make a change and run the project, without saving, and the build fails; every subsequent run of the build uses the same increment. Then I save, and run [cc.net](http://cc.net), and we’re back to square one.
So basically, we can run FB to get our build correct, no failures. Build increments 1, 2, 3, 4, 5, 6, and each build will label in Fortress. Then we switch over to [CC.NET](http://CC.NET), and the first first time it builds, we get a build increment of 1 (which fails, because Fortress already has that label). So we go into the FBV, up the default value to 10, save, go back to [CC.NET](http://CC.NET).
Time passes, we increment up to, say, 100. We find we need to look at something in the FBV project. We open it, close it, and later the build in [CC.NET](http://CC.NET) fails with an error message - label of 11 already exists.
Or, we need to make a change in the FBV project. We open it, change it, run it, label of 11 already exists. We up the default value to 101, run it, get a green build, save it, close it.
Run [CC.NET](http://CC.NET), build fails - label of 102 already exists.
---
### Author:  [@angus](https://www.finalbuilder.com/forums/u/angus)
#### Post date: [April 23, 2008, 1:39am UTC](https://www.finalbuilder.com/forums/t/persistent-variables/2748/19 "2008-04-23T01:39:33Z")
Hi Andy,
Thanks for the reply and explanation. There was a bug involving the unexpected reset of Persistent variables with “Make Available as Environment” enabled, which was fixed in the latest official release. It seems to have missed the Version History changes list, I’ll fix that ASAP.
Could you upgrade to build 707 (available from the Download page) and see if the problem persists, please?
Regards,
Angus