Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • World
  • Users
  • Groups
Skins
  • Light
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (No Skin)
  • No Skin
Collapse
Code Project
  1. Home
  2. Web Development
  3. ASP.NET
  4. Can't resolve for a while. Link button in a datalist

Can't resolve for a while. Link button in a datalist

Scheduled Pinned Locked Moved ASP.NET
databasequestion
26 Posts 3 Posters 0 Views 1 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • N N a v a n e e t h

    Mark Nischalke wrote:

    A better solution to in-line SQL? Ever heard of stored procedures?

    It's a myth. IMO, nothing wrong with inline SQL other than the difficulty of recompiling code when the DB structure changes. This can be avoided by abstracting the table structure using views. So still you can write inline SQLs safely. Please do correct me if you felt I am wrong.

    Navaneeth How to use google | Ask smart questions

    N Offline
    N Offline
    Not Active
    wrote on last edited by
    #21

    N a v a n e e t h wrote:

    Please do correct me if you felt I am wrong.

    Where do I start? This argument has been raised several times. Inline doesn't allow for separation of the business logic from the presentations, which a good design does, and increases maintenance and development. 10 apps with the same SQL statement must each be changed, rather changing one stored proc. Worse yet, if the schema changes, say a table or column is renamed, all statements must be changed instead of changing one stored proc. Inline statements also don't allow the RDBMS to optimize the execution or otherwise cache it for better performance. Just few of the many reasons. Then again, if you don't care about robust, well designed and performant applications, keep using inline statements.


    only two letters away from being an asset

    A 1 Reply Last reply
    0
    • A Albert83

      Sure I heard of stored procedures, I use them when I find necessary. "Response.Write("dr" + dr[0] + "
      ");" is for testing purposes. A lot of programmers do it when testing the results of the query. All the items are templated actually. You are right i mixed it with itemCreated. Thanks for the help.

      N Offline
      N Offline
      Not Active
      wrote on last edited by
      #22

      Albert83 wrote:

      A lot of programmers do it when testing the results of the query.

      :omg: :wtf: A lot of novice programmers. Professionals use a debugger.


      only two letters away from being an asset

      A 1 Reply Last reply
      0
      • N Not Active

        N a v a n e e t h wrote:

        Please do correct me if you felt I am wrong.

        Where do I start? This argument has been raised several times. Inline doesn't allow for separation of the business logic from the presentations, which a good design does, and increases maintenance and development. 10 apps with the same SQL statement must each be changed, rather changing one stored proc. Worse yet, if the schema changes, say a table or column is renamed, all statements must be changed instead of changing one stored proc. Inline statements also don't allow the RDBMS to optimize the execution or otherwise cache it for better performance. Just few of the many reasons. Then again, if you don't care about robust, well designed and performant applications, keep using inline statements.


        only two letters away from being an asset

        A Offline
        A Offline
        Albert83
        wrote on last edited by
        #23

        That is true. But if you use a statement only once it's ok to use inline statement.

        N 1 Reply Last reply
        0
        • A Albert83

          That is true. But if you use a statement only once it's ok to use inline statement.

          N Offline
          N Offline
          Not Active
          wrote on last edited by
          #24

          :laugh: :laugh: And if that one statement is executed 1000 times, what does that do for the performance of your system?


          only two letters away from being an asset

          A 1 Reply Last reply
          0
          • N Not Active

            :laugh: :laugh: And if that one statement is executed 1000 times, what does that do for the performance of your system?


            only two letters away from being an asset

            A Offline
            A Offline
            Albert83
            wrote on last edited by
            #25

            I actually meant execution because that's what matters. Used means executed. Any time the statement executed more than in one place it's easier to work with stored procedure, and modify it.

            1 Reply Last reply
            0
            • N Not Active

              Albert83 wrote:

              A lot of programmers do it when testing the results of the query.

              :omg: :wtf: A lot of novice programmers. Professionals use a debugger.


              only two letters away from being an asset

              A Offline
              A Offline
              Albert83
              wrote on last edited by
              #26

              has nothing to do with level. It's a matter of preference.

              1 Reply Last reply
              0
              Reply
              • Reply as topic
              Log in to reply
              • Oldest to Newest
              • Newest to Oldest
              • Most Votes


              • Login

              • Don't have an account? Register

              • Login or register to search.
              • First post
                Last post
              0
              • Categories
              • Recent
              • Tags
              • Popular
              • World
              • Users
              • Groups