DB Calls

  • Creator
    Topic
  • #120069
    MiteshBhatt
    Participant

    Hi Team –

    I am seeing a unusual event wherein we are calling a SQL STORED PROCEDURE using a DB Protocol is returning the same message, 16 times.

    Each DB record is multiplied 16 times for some reason and is seen in inbound SMAT.

    We are on v19.1.2.OP, if anyone has seen something like this pls. let me know.

    Any help will be appreciated.

Viewing 3 reply threads
  • Author
    Replies
    • #120070
      Peter Heggie
      Participant

      Does your stored procedure also update the source data to ensure the row is only returned once? Or does the Success Action SQL update the source data to ensure the row is only returned once?

      Perhaps the stored procedure is being executed sixteen times per minute, and the query criteria is limited to one minute of time range?

      So I am thinking there is not a bug, but I don’t know the query, or if Advanced Scheduling is used. We are on v19.1.2.0P also. Are you connecting to SQL Server?

      And when you run the stored procedure in a SQL tool it only returns one row?

      Peter Heggie

    • #120090
      MiteshBhatt
      Participant

      Hi Peter – My SP doesnt update. Just does a selection.

      Also,

      If I am connecting to SQL Server through v6.2 and calling a stored procedure it is returning the same count as it shows in SSMS (SQL Mgmt. Studio).

      But if I am connecting the same SQL instance and calling the same stored procedure through v19.x, it is returning the record in SMAT DB for 10 – 16 times.

       

       

      Attached are the screenshots –

      1. SSMS_476_records file : Shows how SQL SSMS’s output — 476 records
      2. Cloverleafv19_5777_records : Shows 5000 some messages in v19 —- looks like a bug
      3. Cloverleafv6_476_records : Shows the same count as shown in SSMS, count matches, no issues
      Attachments:
      You must be logged in to view attached files.
    • #120094
      MiteshBhatt
      Participant

      It’s all TEST Data.

    • #120109
      MiteshBhatt
      Participant

      Here’s what it turned out, the advance scheduling had * in seconds section.

      So the way it read HH:MM:SS and I had sent it to run at 12:01:* instead of 12:01:00

      With * it will run multiple times at 12:01 if it finishes within 60 seconds.

      Turned to be a configuration issue.

      Problem solved.

Viewing 3 reply threads
  • You must be logged in to reply to this topic.

Forum Statistics

Registered Users
5,074
Forums
28
Topics
9,252
Replies
34,235
Topic Tags
275