I have a gridview on my "second" page with a SqlDataSource. The data source is configured to take the qurry string "arg" from the url and run a stored procedure with it.

On the "first" page i have a gridview and one collumn is links. Click on this link and it sends you to the "second" page with the qurry string in the url.

This is the buttonlink event code

if (e.CommandName == "AssetName")
        {
            Response.Write("<script type='text/javascript'>window.open('UsageInformation.aspx?arg=" + e.CommandArgument + "','_blank');</script>");
        }

So when i click on the buttonlink on the "first" page I get a new window with the correct url:

http://localhost:4513/WebSite2/UsageInformation.aspx?arg=XFM_UG:#306:100099462

but the gridview does not load. I can in fact open a new browser and put this url into it and the same thing happens. Everything else on the page loads but the gridview! It's like the sql data source is not passing any information or it is using a null qurry string. But the qurry string is not null.

Thanks in advance for any help!

Dani AI

Generated

The problem turned out to be how browsers treat the # character: it begins the URL fragment (client‑side anchor) and everything after it is not sent to the server. That’s why your SqlDataSource on UsageInformation.aspx only saw XFM_UG: — the #306:100099462 was a fragment handled by the browser, not part of the query string the server received. ’s observation lines up perfectly with that behaviour; ’s suggestion to try a known ID is a good way to isolate the issue when debugging.

Fixes (pick one that fits your flow):

  • Encode the parameter before putting it into a URL so # becomes %23. On the server use URL encoding so the browser will send the full value back:
    string url = "UsageInformation.aspx?arg=" + Server.UrlEncode(deviceAlias);
    Response.Redirect(url);
  • If you must build the URL in client JS (window.open), use encodeURIComponent:
    window.open('UsageInformation.aspx?arg=' + encodeURIComponent(deviceAlias), '_blank');

    Either approach will cause the browser to include the encoded form in the HTTP request; ASP.NET will decode it and SqlDataSource’s QueryStringParameter will receive the original value with #.

Quick tips: inspect the network request in the browser dev tools to confirm what was actually sent; manually test the encoded URL (use %23) to verify server behavior; and be careful with other reserved characters (&, +, ?) — always URL‑encode user/DB values before composing query strings. Using HyperLinkField or a server-side Redirect avoids ad‑hoc script emission and reduces these encoding pitfalls.

If you think the asp sqldatasource code might help here it is. Need anything else please let me know.

<asp:SqlDataSource ID="SqlFPDataSource" runat="server" 
            ConnectionString="<%$ ConnectionStrings:MyConnectionString %>" 
            CancelSelectOnNullParameter="false"
            SelectCommand="MyStoredProc" 
            SelectCommandType="StoredProcedure">
            <SelectParameters>
                <asp:QueryStringParameter DefaultValue="" Name="deviceAlias" 
                    QueryStringField="arg" Type="String" />
            </SelectParameters>
        </asp:SqlDataSource>

Alright!
Good news is that i found the problem!
Bad news is that I have no idea how to fix it!

So in the page_load method I put the following code

string test = Server.HtmlEncode(Request.QueryString["arg"]);

and test was only equal to: XFM_UG:
When I changed my code to do a response.redirect rather than a response.write I get this as my value: XFM_UG:#306:100099462

So the question is... why is my query string different with exactly the same url?!?!?

Thanks so much for any help!

SOLVED:

All I had to do was replace the "#" with "%23" just did a

newString = oldString.replace("#","%23");

And that took care of it. Very odd though, it did not need to be excaped when i did the response.redirect only the response.write...? well anyways it works.
The ":" character gets excaped automatically, which is the wierdest thing.

Well anyways. Thats the solution.

Is the query string your second grid is expecting correct? i.e. RowID

Have you tried entering the query string manually using a known RecordID in the database and see if that works.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.