Pass Dataset Between Pages

[RobHudson]

Hi

I am trying to find a way to pass a dataset from one page to another.

My idea is to ultimatley have a pop up that shows a list of data that has been found from performing a search on the calling page. Nothing to special there really! The problem that I am having is that I do not want to use session variables or the like [long story!]. I need the receiving page to just get the passed dataset and then apply it to a grid - but any dataset so nothing on the page can be hard coded to look at another page, etc. [if that makes sense!]

I tried the getXML function of a dataset to pass it in the url - but obviously it was too big

Any other ideas?
How do webservices do it?? Is that an option??

Thanks
Rob

 

[link9]

Depending on the size of the dataset, hitting the database again for the data based on parameters passed via querystring is a very viable option... especially if you're using SQLServer.

The native provider for SQL Server is extremely fast in .NET.

If that simply isn't an option, then you might consider the .writeXML function of the dataset, and persist it to a temp file, pass the location via querystring, and then .readXML from that location on the next page to re-capture your data. This is serialization of the dataset, and is also a very viable and good performing option.

.writeXML:

http://msdn.microsoft.com/library/d.../frlrfSystemDataDataSetClassWriteXmlTopic.asp

.readXML:

http://msdn.microsoft.com/library/e...emDataDataSetClassReadXmlTopic.asp?frame=true

hth!
paul

 

[RobHudson]

Thanks for that Paul

Writing and reading an xml file could be the way forward

Just in case that proves not to be viable - do you know of a way of doing it purely in code?

 

[link9]

No, I do not, short of persisting it to session, which I certainly would not recommend.

I'd definitely go the "hit the database twice" route before I did that.

And speaking of that method, I know it doesn't feel right, but I'm not kidding when I called it very viable. Performance has been vastly improved over past versions of ADO, and even the "experts" (whatever that means) are saying that hitting the database twice will, many times, be the best solution for a situation like this.

I guess performance testing against the two methods would be in order, if you really are trying to squeeze as much as possible out of your app.

The Microsoft Test Center application that ships with VS Enterprise Developer & up is a great app for doing just that (testing, I mean).

good luck!
paul

 

[Isadore]

Paul, quick question.

I think the XML route is certainly attractive, and would have to agree that it is probably the best route to take. The question I have however is this: at one place in my website I put 4 small datasets into Session (had them in cache and changed that), each dataset holding about 12 x,y variables of information (say one string, one double).

True, Session state should not be leaned on, but on the other hand its there, works well, and for small parameters, or small datasets, wouldn't you expect the server, memory, etc... to up to snuff to handle small datasets, sparsely put into Session?

 

[RobHudson]

Paul, now worries

The reason I was not keen on hitting the db twice was purely because I want to use the pop up in other apps and do not want to have to keep modding it each time a different set of search results are used in it.

I think the xml route is the way to go...

Thanks
Rob

 

[link9]

Isadore,

There isn't a single instance of any practice that I would say absolutely NEVER do, and that a particular situation is ALWAYS the best... etc...

If you know the level of your site traffic, and know that your datasets will only take up x amount of resources, and you are completely comfortable with that (assuming you have taken everything into account), and would opt for the simplicity of placing objects into session, then I think that's just fine.

The "end" that we're after in this game is performance (in nearly every case), and if you're happy with the end that you receive, then IMHO, any "means" you use to get there is just fine.

Personally, I don't do it. But that's strictly a design decision and policy that I enforce on myself to make sure that one day, I don't decide to cut a corner and put a big one in there. Just a discipline, and nothing more.

Any good developer, though, has a grasp on his/her requirements, and can make much better informed design decisions than I could, as a helper, here in this forum.

As a rule, I don't go into this long explanation of my reasons for suggesting things a particular way... but rather just suggest people do it like I do, and trust that if they follow my suggestions, hopefully (and I stress, HOPEFULLY) everything will turn out OK. Most people wouldn't want to read all this mess, and it would certainly confuse the issues if I put it as a caveat every time I suggest someone NOT use session to store objects.

What I'm trying to avoid is the aggregious mis-use of this practice that writers in magazines love to just throw around like it's the "right" way to do it. I know you've read e-zines and traditional paper mags where writers use it, and IMHO, that just gives the wrong impression to a new programmer just warming up to the concepts of web development.

Gee, I hope that was long-winded enough to get my point across.

That's my story, and I'm sticking to it.

;-)
paul

 

[Isadore]

Thanks Paul. I completely agree and understand. In my situation, there is no harm done, albeit an XML stream could perform adequately and with good speed.

And I agree with you that "Session state" is somewhat loosely thrown around in the literature while not treating the server drawbacks in much detail. But as you suggested, one need only evaluate the byte required for x number of users per y time, etc..

Interestingly, ESRI has recently opened up Arc Internet Map Server (IMS spatial database) with XML streaming capabilities. A very powerful platform to connect to ASP.NET/SQL.