Skip to main content
cancel
Showing results for 
Search instead for 
Did you mean: 
datanibbler
Champion
Champion

Server_swap: How to quickly change every INCLUDE statement?

Hi,

we are going to have a server swap here in two weeks which means we are going to have to adapt quite a lot:

- In every single qvw we have, there are a number of INCLUDE statements, all on one sheet of the script afaIk, which point to a place on the server - since the server does not know the drive_letters, we have written out the URL in every one of those

=> so we'll have to open every single qvw and replace that.

Okay, that is not too much work for one - just step through it with find_replace - but every single one, and some of them are huge, so they take a bit to open ... isn't there a faster way we could do that?

Thanks a lot!

Best regards,

DataNibbler

1 Solution

Accepted Solutions
datanibbler
Champion
Champion
Author

Hi Bill,

you're right - but we're turning in circles.

Like I said, relative paths don't work for me because from that "QlikView_server" which is really just one partition of the main_server, I cannot go up three or four hierarchy-levels and end up in some directory on the main_server - doesn't work. End of story.

I am just asking for confirmation of what I know about the servername-to-be, then I can build up an IF_THEN clause like I said. So the actual swap will be automatic and I will just have to do some cleanup in the weeks after that date.

Best regards,

DataNibbler

View solution in original post

16 Replies
Gysbert_Wassenaar

If you implement something like the QDF you could prevent this in the future. But, yes, that does not help you now.

I did see that it is possible to get and set the script content using the com api. So I think you could write a vbscript macro to run through a list of qvw files, change the script and then save the qvw again.


talk is cheap, supply exceeds demand
Anonymous
Not applicable

Don't know of any quick ways that won't actually take longer [i.e. you could create -prj folders for each qvw and do find replace on the affacted xml's...... I would not recommend that]

I usually store all file locations in an external xls that is then loaded into the script to populate variables, as then just this needs changing and the changes will happen on the next reloads.  Maybe when you are going through your qvw's you could implement this for the next time things change.

datanibbler
Champion
Champion
Author

Hi Bill and Gysbert,

I am doing something in that direction (centralization) - I have all the paths to Excel-source-files and partly to qvd files holding the base data for my apps in qvs files (txt files) on the server - one per area so they can be parsed quickly - these are loaded into the scripts using INCLUDE - but, like i said, these txt files are on the server and since our server doesn't know its own drive_letters, they are loaded using the complete URL - so these are what I need to change.

Best regards,

DataNibbler

P.S.: Installation of any additional tools is not really an option in here - I cannot do it myself since all the laptops are centrally administered, so I'd have to go to IT and until installation of anything is tested and checked and backchecked and finally approved - and then actually done ... I think then it will still be easier to open every single qvw and just do find_replace in the script since the INCLUDEs are all on one sheet of the script.

Peter_Cammaert
Partner - Champion III
Partner - Champion III

A second step in your "centralization" effort, and one that Gysbert already alluded to is to take a rule from the Framework book (there are many different frameworks, one per QlikView Enterprise installation that is actively used and survives for more than a few years). Let me explain in too many words (sorry):

The weakness in your set-up is that every document script contains a script element that needs to be modified. Document scripts are by definition rather inaccessible for performing a sweeping adjustment. That's the main reason why many articles/best practices suggest to externalize settings and put them in a single place.

However, there is still a single point of failure: where do we start referring to the external settings? In a framework set-up the answer is simple: from the start in the document script. And at that very moment a framework brings another big trick (the most important one in this situation I think): all locations of scripts, documents, QVD's, configuration files etc. are at fixed places, relative to whatever you have opened at the moment.

So my suggestion would be to create an initial settings.ini file that contains a few fully qualified paths that you really need (but not much else), put that file in a central fixed spot with respect to your QVW documents (whether they be QVD generators, Dashboards or whatever) and in your document scripts INCLUDE this settings.ini file at the front and using a relative path. After that you can do as you like using the imported fully qualified paths, and still make your document(s) location-independent.

Of course, this is just a suggestion as I'm still unaware of the details of your current enterprise environment. Your mileage may vary.

Best,

Peter

Anonymous
Not applicable

Yup, I agree with Peter - apart from I hard code the relative path to where I hold the file that contains my folder locations.

datanibbler
Champion
Champion
Author

Hi Bill and Peter,

if I understand you correctly, what you suggest is just what I have been doing for a long time - with the difference that I always use absolute paths in my script:

- In the script of every qvw I have one sheet that always looks m.o.l. the same, it holds a number of INCLUDEs

=> Every one of those INCLUDEs points to a fixed location (using a fully-qualified path) where there is a txt file

=> That txt file (like I said there is roughly one per area so they can be parsed quickly) holds the fully-qualified paths

      to Excel-source-files and qvd files.

I have already made new versions of all these txt files (rgd. the Excel_files) which I'm just going to swap for the old ones when the server-swap comes around. The qvd_files are not an issue, either, as I'm told that the path to the "QlikView_Server" (a dedicated section of the company_server) will remain the same.

=> So the only point_of_failure that remains is that one sheet per qvw with all the INCLUDEs.

You're right, I could swap these for relative paths and I'd have no problem - the issue is just, I don't know whether that would work because, even though QlikView is hosted on one section of the company_server, it has a different URL and I don't know whether, using a relative path, I could access locations on the "main_server" from the "QlikView_server". Well, that just needs testing.

I will try as I can foresee that there will be a lot of work on that and the subsequent day, and a lot of people doing a lot of shouting, and if there's some part of the load that I can reduce by doing some work in advance, it's worth a shot 😉

Thanks a lot!

Best regards,

DataNibbler

Anonymous
Not applicable

Put only the config file that contains the other folder locations in a folder that can be successfully referred to via a relative path.

In that single file that defines your other folder locations these folder locations held in it can be in whatever format works for you - relative, fixed, unc, "url" ro whatever ..............

This change can be done carefully one qvw at a time pointing your current folder locations via the new relative folder location for your other folder - and tested in advance of the server swap over.

For the actual server swap over just change your folder locations config file in the relative folder location and simply reload your qvw's

Peter_Cammaert
Partner - Champion III
Partner - Champion III

I think you understand my point. But just to make sure: the only relative path I use is the path (hard-coded, as Bill says) to the single settings.ini file. For example, if my QlikView document is located in 02 Models, and my settings.ini is located in 11 Script\General (both paths start in the same subdirectory), my document script starts with:

$(INCLUDE=..\21 Script\General\Settings.ini)

As long as I mantain these locations relative to each other, nothing will need to be changed in the document script.

If my Settings.ini file now contains statements like these:

SET vPath=\\QlikView_Server\d$\In Production\Private\;

SET vDataPath=$(vPath)\11 Data\QVD\;

SET vExcelPath=$(vPath)\11 Data\XLS\;

SET vXtraData=\\main_server\ShareName\Data\; // other machine

:

my document script can still refer to many locations (by referring to variables vPath, vDataPath etc.) without them being hard-coded in my script. And if I change a location in settings.ini, it automatically changes for all documents.

In any case, good luck with the overhaul.

Best,

Peter

datanibbler
Champion
Champion
Author

Hi Bill,

I was just going to test that - but how to write it? I think I know how to write relative paths - e.g.,

>> ..\newdir << tells QlikView to step one hierarchy higher and then into the >newdir< - but regardless whether or not I tick the checkbox "relative paths" in the script_editor, QlikView tries to find a directory labeled "..\newdir" (to stick with the example) INSIDE the directory where the qvw is located ...

There must be some stupid error here. Can you help, please?

Thanks a lot!