you could use VBScript macro code like this:
I am not sure what's best, checking within your application or beforehand, IMHO it's depending on what your want to do with this information.
For example ,you could use above code snippet in a macro called from your script and then stop execution and alert the administrator, maybe.
Anyway, hope this helps,
Just using the Function part of the script in Stefan's link, this can be called in the load script as follows ...
For i = 1 to $(Tmp)
If vb_in <> 0 then
LOAD website, 'Valid' as validURL resident WebSite where website='$(url)' ;
LOAD website, 'Broken' as validURL resident WebSite where website='$(url)' ;
// Loop creates some nulls which need clearing out
tmp: NOCONCATENATE LOAD DISTINCT * resident WebSite where Match(validURL,'Valid','Broken') > 0;
DROP TABLE WebSite;
RENAME TABLE tmp to WebSite;
Thanks for your support gyus.
The solution you both provided works for verifying that the domain is valid or not, but it doesn't work for my image urls.
The links are as I wrote links to either documents or images, often the link is a url like this:
That is - it's a database request-url "post", and the result is a "redirect" to a new url with a "real" imagelink.
so you get a lot of 'broken' results though the link is valid?
The referenced code snippet only checks for html return code = 200 (OK), if a redirect is returned, you get html return codes in the 3xx range. Maybe it's just enough then to change the check in the macro code from equal 200 to < 400. Give it a try.
And/ or you may try to debug into the code and have a look what's returned in your real environment.
Hope this helps,
I tested my document from home and here it works great, so the problem is that I have to handle the proxy servers at work....
So now I have to figure out how to setup WinHTTP with proxy support.
I have seen the function SetProxy for the WinHTTP object,
But I don't get it to work, I think our proxy also requires a login, but I am not sure yet.
Anyway, the solution works when I'm not inside the office... Thanks again for all help!
I rewrote the load script like this:
LOAD @1 as Link, PingSite(@1) as status
FROM welinks_source.txt (txt, codepage is 1252, no labels, delimiter is '\t', msq);
Skipping the For Next Join part completely, and instead having the function "PingSite" handle more of what to give back to the load script, makes the script more simple to read.
I was not aware that it was possible to write functions to be used in the load script. This functionality is superb, gives me a lot of ideas how to solve other challenges!