Is there a session variable? Microsoft please help

Is there a way to access a session variable for the url in reporting services? This is hard to explain, but our internal users access our website and view reports via one url, while external users use a different url to view the website and reports. I used the jump to url in some of my reports, but I need the report to read which url they came in on so that it can jump to the correct url that I need it to. Has anyone done anything similar to this?Anyone have any ideas? I use "jump to url" in quite a few of our reports w/ the link that it is jumping to being different information on our website. Our internal users see our website on a different url than our external users, so in my jump to link I need to conditionally set whether they go to the one url or the other, but I have to determine how they came in to begin with to determine which one they jump to.

Is there a session variable?

Is there a way to access a session variable for the url in reporting services? This is hard to explain, but our internal users access our website and view reports via one url, while external users use a different url to view the website and reports. I used the jump to url in some of my reports, but I need the report to read which url they came in on so that it can jump to the correct url that I need it to. Has anyone done anything similar to this?Anyone have any ideas? I use "jump to url" in quite a few of our reports w/ the link that it is jumping to being different information on our website. Our internal users see our website on a different url than our external users, so in my jump to link I need to conditionally set whether they go to the one url or the other, but I have to determine how they came in to begin with to determine which one they jump to.

is replication session a transaction?

I am curious if a "session" for merge replication is a transaction. If I
see 100 actions in the Agent History and the last one is "the process could
not enumerate changes at the subscriber" due to General Network Error
(dropped connection or whatever), did those 10000 data changes get
committed or were they all rolled back and the next agent run will start
that all over again.
Assuming the negative possibility, what profile parameter would I change to
reduce the number of rows before a commit? Our agents for low-bandwidth
subscribers are running for hours and hours and never seem to catch up
because they always eventually lose the connection.
Thanks for any insights.
They are committed as singletons. So a batch of 100 (by default or whatever
is in the Upload|DownloadWriteChangesPerBatch) is tried and if errors
occurred while applying a batch the error rows go into a retry look which is
tried after the batch completes.
Should an network error occur during a synchronization, the merge agent will
look at the last batch successfully applied and then start to apply the next
one again. There is a possiblility that should 99 of the rows in the last
batch make it through, all 99 will be tried again to push the last one
through which was not successful.
You will notice that the slow link profile drops these values from 50 to 1
(or 5 for UploadGenerationsPerBatch).
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
Looking for a FAQ on Indexing Services/SQL FTS
http://www.indexserverfaq.com
"Anachostic" <anachostic@.remove.700cb.net> wrote in message
news:Xns995CA07258BD9anachostic@.207.46.248.16...
>I am curious if a "session" for merge replication is a transaction. If I
> see 100 actions in the Agent History and the last one is "the process
> could
> not enumerate changes at the subscriber" due to General Network Error
> (dropped connection or whatever), did those 10000 data changes get
> committed or were they all rolled back and the next agent run will start
> that all over again.
> Assuming the negative possibility, what profile parameter would I change
> to
> reduce the number of rows before a commit? Our agents for low-bandwidth
> subscribers are running for hours and hours and never seem to catch up
> because they always eventually lose the connection.
> Thanks for any insights.