#1
|
|||
|
|||
Problem using Vault
I am using the latest version of VBP (6.2a) and the latest version of Vault (3.5.1). When I have my Vault database configured as localhost, VBP decides it does not need to enter the vault -host option. Vault, however, does not like this and fails with:
<vault> <error> Please specify -user, -password, and -host. </error> <result success="no" /> </vault> I verified from the command line that if I simply add a -host localhost to the command string produced by VBP, all is fine. I could add the -host option to all of my Vault commands, but this is really something that VBP should be doing for me. Last edited by Dave_Novak; 02-14-2007 at 12:18 PM. |
#2
|
|||
|
|||
It would probably be better if Vault.exe assumed localhost if not specified, since not all commands accept a -host flag. We'll add to our list to pass -host localhost (for commands that require it) if not specified in the action itself.
For now, you can add a temporary Run Script action (VBScript) to your project and rebuild it to change all Vault steps with a blank Host field to 'localhost': Code:
' change all blank Host fields on Vault steps to localhost For i = 0 To vbldStepCount-1 For Each objStep In Application.Project.Steps(i) If objStep.Action = "Vault" Then If Len(objStep.Property("Host")) = 0 Then objStep.Property("Host") = "localhost" End If End If Next Next |
#3
|
|||
|
|||
Just to be clear, all of the Vault commands I use right now already make use of a project macro %VAULT_SVR% in the Host field on the Server tab. Therefore, I am specifying a host value to use in my Vault actions. However, when value of %VAULT_SVR% is localhost, VBP ignores it. I think this is a bug.
Having said that, I also agree that Vault should default to localhost is no host param is given. I will write a post for them as well (though they are typically slow about making changes.) In the meantime, however, I think your software should be updated to take whatever value the user enters into the host field. |
#4
|
|||
|
|||
Yes, but some commands don't, so the Vault action needs to account for those (even if you don't happen to be using them).
And the Vault action *does* use whatever value is in the Host field (as long as it's not blank). So if that field references a macro whose value is 'localhost', it will add -host localhost to the command. I verified this by changing the VAULT_SERVER macro in the Vault.bld sample to localhost and setting SHOW_CMD to 1, using VBP v6.2a. |
#5
|
|||
|
|||
My sincere apologies as this was all completely my fault. I ended up making a non-obvious but rather stupid mistake. As I explained before, I indeed do have a project macro (or rather a global macro) %VAULT_SVR% which is defined as localhost and is in the Host field (on the Server tab) of every Vault action. This way, localhost should be my default if an override is not provided.
Where I messed up, however, is that all of my Vault logic is buried in global subroutines, which at the highest calling level takes %VAULT_SVR% as a parameter. I’m sure you’ve guessed it already now, but my logic for initializing %VAULT_SVR% as a parameter worked fine when an override was specified but failed to revert to the global default (localhost) when none was specified. My apologies once again for the wild goose chase. VBP is doing exactly what it is being told to do! Last edited by Dave_Novak; 02-20-2007 at 07:38 AM. |
|
|