Forum Replies Created

Viewing 15 posts - 1 through 15 (of 28 total)

  • RE: Deadlock graph/report experts wanted :)

    BREAKTHROUGH! 🙂

    Starting with a clear mind today, I took paper and pencil to hand and plotted out the timeline from the deadlock report.

    Looking at the timestamps in there...

  • RE: Deadlock graph/report experts wanted :)

    Thanks Perry, but correct me if I'm wrong but that would only help if I was "witnessing" the actual blocking/deadlocking, right?

  • RE: Stored Procedures slower than queries

    lnardozi 61862 (1/17/2016)


    On the app side, adding a row to be processed is done by adding a row to the table-valued parameter. One common way to do that is to...

  • RE: Stored Procedures slower than queries

    Sergiy (1/17/2016)


    Stijn977 (1/15/2016)


    took me a minute to realize what you meant, but I think you mean:

    use ISNULL everywhere

    for those fields which allow NULL : use CASE ?

    No,...

  • RE: Stored Procedures slower than queries

    lnardozi 61862 (1/15/2016)


    Yes, from within the proc there is the exact same 'problem'. However, it is from outside the proc you will notice dramatic performance improvements. Let's say you put...

  • RE: Stored Procedures slower than queries

    The code example you posted as "finalised" excludes all NULL variables from the UPDATE altogether.

    That's correct. But because I am using sp_execute SQL there is a workaround and I 'could'...

  • RE: Stored Procedures slower than queries

    serg-52 (1/15/2016)


    Sergiy (1/14/2016)


    Apart from that.

    How do you deal with concurrent updates?

    If 2 or more users edit the same record in their independent instances of C++ application - which version of...

  • RE: Stored Procedures slower than queries

    lnardozi 61862 (1/14/2016)


    in this case the application code has processed all changes in memory and needs to (at set times) write all changes to the database.

    I'm surprised no one...

  • RE: Stored Procedures slower than queries

    MMartin1 (1/14/2016)


    If this is indeed the case, I am not sure why updating one field means blanking out the other, but as I mentioned I am probably missing a thing...

  • RE: Stored Procedures slower than queries

    Hi Michael, appreciate the points you raise! I haven't had time yet to look into the practicality of 'temp table' based updates in my case, do you mind if I...

  • RE: Stored Procedures slower than queries

    Hi Serg!

    Those groups of INSERTS & UPDATES are one business transaction.

    I wouldn't say the DB is a backup facility. When I say stuff gets updated/inserted every now and...

  • RE: Stored Procedures slower than queries

    @ Michael,

    A very good observation that I "might not have a problem". This is fortunately true at the moment. I am trying to anticipate our application scaling up users,...

  • RE: Stored Procedures slower than queries

    Hi Sergiy, appreciate you joining the discussion.

    Unfortunately your idea isn't fitting for me because:

    - if the update runs, it would update all fields of the table (in case of...

  • RE: Stored Procedures slower than queries

    Heya, I'm trying to update a lot of different rows, each needing different fields updated. So set based approach does not qualify I'm afeaid. Unless I am missing something.

    But thanks...

  • RE: Stored Procedures slower than queries

    Hi abdullah!

    Thank you for your input. 🙂

    i've already experimented with turning on workload for ad-hoc (as well as altering the db to turn on forced parameterization). Unfortunately not with good...

Viewing 15 posts - 1 through 15 (of 28 total)