Results 1 to 8 of 8
  1. #1
    Join Date
    Sep 2010
    Posts
    22

    Unanswered: Temporary Tables

    Long story short is that a user inputs a lot of data in an ASP.NET/C# pop-up window. That data needs to be added to a table, but can't be input into the table until the last process of the interface is reached (because that's what creates the table's primary key, and until we have the primary key, we can't add anything to the table). In short, we need a place to store the load of data the user input in the pop-up window until the end of the interface is reached.

    The easiest solution that my newbie mind could think of is to create a temporary table to store this information, and then at the end of the process, when we have our primary key, just copy over the data from the temporary table to the real table, then clear out the temporary table.

    Otherwise, we have to worry about storing the data in like an array or DataTable variable, passing that from pop-up to parent window, and then preserving that across postbacks until the end of the interface is reached. Part of the problem is that the user can open up the pop-up window multiple times to input multiple sets of data. For each set entered, the pop-up would have to determine if there's already a DataTable being stored in the parent window, and if so, append the data to the already-existing DataTable, or if there isn't already a DataTable, create a new one. One measly temporary table would solve this in like one line by simply adding a row for each set of data entered.

    However, if I'm not mistaken, it is generally considered bad practice in programming to use temporary variables when there are other alternatives. Of course I would like to keep my database as clean as possible, but simply keeping this data in a temporary table would solve all of my problems without cluttering up the ASP.NET/C# code with all of this preserving the data locally across postbacks, blah blah blah.

    Am I on the wrong path to solving this problem?

  2. #2
    Join Date
    Feb 2004
    Location
    One Flump in One Place
    Posts
    14,912
    Personally I would store this data in session variables in the ASP.NET session. I would not use SQL Server as a cache in this manner.
    Testimonial:
    pootle flump
    ur codings are working excelent.

  3. #3
    Join Date
    Mar 2003
    Location
    The Bottom of The Barrel
    Posts
    6,102
    Provided Answers: 1
    Quote Originally Posted by CptSuperMrkt View Post
    However, if I'm not mistaken, it is generally considered bad practice in programming to use temporary variables when there are other alternatives.
    If I'm not mistaken, you are mistaken. There's nothing wrong with temporary variables, at all. I'd argue that tightly scoped "temporary" variables comprise the bulk of most well factored code. The idea is generally to only spool up a variable when you need it, and then ditch the thing as quickly as possible when it has outlived its usefulness.

    I'd go pootle's route as well. Session is all about giving you a place to store stuff that you don't want to persist to disk just yet, but you want to have it available throughout the user's "session" (meaning preserved across multiple postbacks).
    oh yeah... documentation... I have heard of that.

    *** What Do You Want In The MS Access Forum? ***

  4. #4
    Join Date
    Feb 2004
    Location
    One Flump in One Place
    Posts
    14,912
    I assumed he meant, by temporary variables, creating and accessing SQL Server temporary tables from the FE in multiple round trips.
    Testimonial:
    pootle flump
    ur codings are working excelent.

  5. #5
    Join Date
    Mar 2003
    Location
    The Bottom of The Barrel
    Posts
    6,102
    Provided Answers: 1
    Ohhhhhh....

    Yeah, don't do that.
    oh yeah... documentation... I have heard of that.

    *** What Do You Want In The MS Access Forum? ***

  6. #6
    Join Date
    Jan 2003
    Location
    Massachusetts
    Posts
    5,799
    Provided Answers: 11
    In SQL 2008, it is possible to have a stored procedure with a table valued parameter. I also read something about streaming the input to this table from a .NET front end. Not sure if this would be applicable in your case. This article may do the trick.
    Table-Valued Parameters in SQL Server 2008 (ADO.NET)

  7. #7
    Join Date
    Jan 2003
    Location
    Massachusetts
    Posts
    5,799
    Provided Answers: 11

  8. #8
    Join Date
    Mar 2003
    Location
    The Bottom of The Barrel
    Posts
    6,102
    Provided Answers: 1
    Well, my noodle has officially been cooked. If I'm reading that right, it looks like structured data types are put on the wire after each yield statement fired by the IEnumerable passed as the parameter value... Is that seriously what's going on? That's kind of nuts.
    Last edited by Teddy; 10-12-10 at 17:19.
    oh yeah... documentation... I have heard of that.

    *** What Do You Want In The MS Access Forum? ***

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •