Unlock a world of possibilities! Login now and discover the exclusive benefits awaiting you.
We currently have a single QlikView production server (QVP/QVS on the same box) and our QVDs are kept in the default location: C:\QlikView Storage\Private Data\QVD
We have additional servers on order and will need to move our QVDs to a location on our SAN (see architecture diagram below).
Our currently approach works great for our 8-12 QlikView developers since the QVDs are in the same location on their workstations and our production server (C:\...). Because of this they can create a QV application on their workstations (which have the QVDs copied onto them) and we can promote into production without the application breaking (since the paths to the QVDs remain identical). Obviously, this process will need to be changed with our architecture upgrade.
For all of you that are currently storing QVDs on a SAN/Network Share - what is the best way to reference the QVDs?
My ideas:
1) Don't worry about paths, the QV promotion team will fix them when the app is moved into production.
2) All paths should be set with variables so the variables (locations to QVDs) can be switched easily during promotion.
3) Use a variable to reference only the drive letter mapping where the QVDs are stored. This way on a developer workstation you could set it to "C:\" and on a production server you could set it to "Q:\" (you would only need to switch a single variable rather than each of the QVD paths). This would make the assumption that all QVDs are stored at: <var>\ QlikView Storage\Private Data\QVD. "<var>" = C:\ on a developer workstation, and Q:\ on the production servers (which are mapped to SAN locations).
4) Storage location should be mapped to a standardized drive letter (like the Q:\ drive) and all developers should map an identical drive on their workstations for QVDs.
Any comments / suggestions? Thanks in advance!
Hi,
I would recommend a structure like described in that article.
http://www.qlikblog.at/766/qliktip-25-organize-qlikview-projects-file-system/
this is pretty close, to what we use in most projects.
Hope that helps,
Christian
Christian:
I was not previously aware of this blog and I just added it to my feeds. It seems like the blog is advocating for #4 - so relative paths are enforced and utilized. I was a little confused, as it seemed like the post skipped around the physical storage issue and only spoke to the logical organization of directory structure. Great content, but I am really focused on the physical storage medium translating to logical - as in the situation where developers are working on local storage (their workstations) and the production environment is using SAN storage.
-- Thanks for your feedback!
Trevor