If you load manually, in field selector, right click on the data, select Properties and in the Details tab you can see that the File address is the same that i use in the script. I'm not sure what changed in beta2 that this is not working anymore.
Can you please give this a try using today's beta2 nightly? We're still in the process of developing loadFile functionalities, and our testing to this point has been with local files on our machines, not realizing that this had worked with data right off a catalog. Since we didn't notice this, we put in an error check for loadFile that verified that the 'filename' keyword actually pointed at a local file, which is why accessing data from a catalog started to error.
I made our loadFile programmer aware of this, and he put in a fix to allow the filename keyword to point to a catalog. From my testing this morning, this seems to be working now.
Thanks for reporting this - Bob Carp McIDAS Help Desk
Thank you for taking a look into this. I use that script as a example, because the unidata thredds is open, but my real use of this is to load file from the local Threads of the institution that i work. The unidata thredds worked, but my institution's local thredds didn't. The funny thing is that in 1.5beta1 works fine.
Can you post the URL you are trying to use? Well, I don't need to the actual URL, just the "form" of it.
All I'm trying to do is add some simple error checking to loadFile so that it will fail gracefully if a user tries to load a non-existant local file. But thanks to your post, I realize now that we still need to let through any attempt to load remote data. For the moment I went the naive route and am just letting through anything that starts with the string "http". So... if you you can let me know the "form" of your URL I can make sure that case gets handled properly.
Sorry for the hassle, but thanks for letting us know about this... we didn't even realize loadFile works with remote data!
We just updated the nightly build one more time. If you download and install the newest nightly, the "dods://" URL should work. Sorry again about the hassle, but thanks for working through it with us!