Results 1 to 10 of 10
  1. #1
    Join Date
    Oct 2008
    Location
    Denver, CO
    Posts
    44

    Unanswered: Temporary tables with Inserts

    Hi folks,

    I'm trying to create a form in asp.net with several fields and a couple of tables that users can add rows to or edit/delete existing rows. There will be one insert button for the whole form that will attempt to insert all the data into the database. Asp.net has a gridview control which is useful for displaying and manipulating data from a database. I've been working on creating my own class for storing data in a temp table in memory (not in the database) and customizing the commands on the gridview to manipulate the temp data but it's been a nightmare.

    Now I'm wondering about using temp tables in the database to store the temporary data before the user clicks insert and all the data is permanently stored in the correct place. This would be much more convenient for what I'm doing in asp.net. Is this possible? If so, what is the best method? Is it bad practice?

    Regards,

    Paul
    Paul Palubinski

  2. #2
    Join Date
    Feb 2004
    Location
    One Flump in One Place
    Posts
    14,912
    Quote Originally Posted by ppalubinski
    Is it bad practice?
    'fraid so. You should only submit data to the database for permanent storage.

    You have several option in asp.net including table objects (ADO.NET) and object collections.

    You might be better off asking for some help refining your ASP.NET code instead....
    Testimonial:
    pootle flump
    ur codings are working excelent.

  3. #3
    Join Date
    Oct 2008
    Location
    Denver, CO
    Posts
    44
    Thanks for the response. I had a suspicion that would be the case, but figured it would be worth investigating before bashing my head against my keyboard for another two days straight.
    Paul Palubinski

  4. #4
    Join Date
    Nov 2002
    Location
    Jersey
    Posts
    10,322
    OK, Hold on...not to throw a wet blanket on everything, and not to say I like your idea, but......

    If you create a permanent table with the columns you want, AND lets say the host name, each terminal has its own "virtual" storage facility

    Is this a good idea or bad?

    I do not know

    Go ask your Dad

    or test it out
    Brett
    8-)

    It's a Great Day for America everybody!

    dbforums Yak CorralRadio 'Rita
    dbForums Member List
    I'm Good Once as I ever was

    The physical order of data in a database has no meaning.

  5. #5
    Join Date
    Oct 2008
    Location
    Denver, CO
    Posts
    44
    I asked my dad, he said I should ask you guys. I guess he doesn't have all the answers after all. But, man, was he good at helping me with my algebra homework when I was growing up.
    Paul Palubinski

  6. #6
    Join Date
    Nov 2002
    Location
    Jersey
    Posts
    10,322
    we need more details...ddl, ect
    Brett
    8-)

    It's a Great Day for America everybody!

    dbforums Yak CorralRadio 'Rita
    dbForums Member List
    I'm Good Once as I ever was

    The physical order of data in a database has no meaning.

  7. #7
    Join Date
    Oct 2008
    Location
    Denver, CO
    Posts
    44
    I don't really know what DDL you want to see?
    Paul Palubinski

  8. #8
    Join Date
    Feb 2004
    Location
    One Flump in One Place
    Posts
    14,912
    Quote Originally Posted by Brett Kaiser
    OK, Hold on...not to throw a wet blanket on everything, and not to say I like your idea, but......

    If you create a permanent table with the columns you want, AND lets say the host name, each terminal has its own "virtual" storage facility

    Is this a good idea or bad?

    I do not know

    Go ask your Dad

    or test it out
    You reckon there's mileage pushing data to and from the database layer in order to meet some application requirements?
    Testimonial:
    pootle flump
    ur codings are working excelent.

  9. #9
    Join Date
    Feb 2009
    Posts
    2
    I had a similar problem with a number of tables accessed via ASP.NET.

    My problem seems similar to yours in that I needed a temporary storage area where a number of pages could update tables in a transaction.

    I created a separate "PropertyBag" database that contains duplicate tables with one additional column per table.

    For a greatly simlified example let's say we have an Employee table in the main DB consisting of EmpID, FName, and LName. In the PropertyBag there would be an Employee table with PBID, EmpID, FName, and LName. The ASP page writes to the PropertyBag and when done, the final page executes a stored proc that copies from the PB to the main database tables and cleans up. All of the ASP pages comprising multiple input screens kept track of the PBID for that entry.

    My app was actually quite complex and there were reasons for creating a separate database instance for the PB but you get the idea.

    Hope this helps.

    P.S. As I said, this is a greatly simplified example, the real app had fields such as UpdateDate and logic to clean up the PB should the user cancel in the middle so as to not leave old unused records in the PB tables.

  10. #10
    Join Date
    Jun 2003
    Location
    Ohio
    Posts
    12,592
    Provided Answers: 1
    Agree with Pootle here. The database should not be used for storing information that is merely incidental to the interface functionality. Its a matter of scope.
    If it's not practically useful, then it's practically useless.

    blindman
    www.chess.com: "sqlblindman"
    www.LobsterShot.blogspot.com

Posting Permissions

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