• You are here:  
  • Home
  • Q&A
  • Q&A
  • PowerServer
  • Stored Procedure being fired during PowerServer Build/Deploy

Subscribe via RSS
Toggle Submenu
  1. Categories
  2. Recent
  3. Tags
View Replies (2)

Resolved Stored Procedure being fired during PowerServer Build/Deploy

  1. Issue
0
Votes
Undo
  1. Jeff Gibson
    Jeff Gibson
  2. PowerServer
  3. Tuesday, 27 August 2024 19:45 PM UTC

PowerBuilder 2022 R3 Build 3356

SQL Server 2022

We have an application that when a cloud project is being built in PowerServer, it in turn triggers stored procedures that start processes that are a part of the audit/logging process for their billing module.

The stored procedure that is being inadvertently fired is tied to a datawindow within their environment.

My question is this...

When a cloud project is being built and deployed (this is when this database action is getting inadvertently fired), and the Web-API's are being built out for the datawindows/stored procedures. Are the stored procedures being executed by the process, by design?  We were under the impression the datawindow/stored procedure would be interrogated, not fired.

We can duplicate this, because the table that is having data placed in it, is empty when we start the build/deploy process.

Any thoughts on getting around this would be greatly appreciated!

  1. DataWindow
  2. PowerServer
  3. Stored Procedure
ETA for next PB 2022 R3 MR
Running on "Secured-core PCs"?
Accepted Answer
Francisco Martinez @Appeon
Francisco Martinez @Appeon Accepted Answer Pending Moderation
  1. Tuesday, 27 August 2024 19:58 PM UTC
  2. PowerServer
  3. # Permalink

Hi Jeff,

Yes, the SPs are executed with their default parameters to obtain the data types of the resulting column(s); this is required for generating the appropriate C# models (C# is strongly-typed so it's necessary to know them in advance) and is entirely by design.

 

Regards,
Francisco

Comment
Load more comments
mike S
  1. mike S
  2. Thursday, 29 August 2024 14:10 PM UTC
agree with David - your build/deploy database connection should always be a dev or test database!



  1. Helpful 2
Chris Pollach @Appeon
  1. Chris Pollach @Appeon
  2. Thursday, 29 August 2024 14:21 PM UTC
Agreed. Then use regression approach to restore the dev db to a known state each time. ;-)
  1. Helpful
Jeff Gibson
  1. Jeff Gibson
  2. Thursday, 5 September 2024 16:02 PM UTC
Totally agree. They are not doing builds using the production environment. They just noticed that data was being inserted into their log tables.



David. You're saying just incorporate logic into these specific stored procedures, that if it's that user account, just bypass the logic?
  1. Helpful
There are no comments made yet.
Responses (2)
Mark Goldsmith
Mark Goldsmith Accepted Answer Pending Moderation
  1. Thursday, 29 August 2024 14:00 PM UTC
  2. PowerServer
  3. # 1

Hi Jeff,

I was thinking the same as David as far as utilizing a development database. A couple of other options come to mind:

1) You could disable the trigger(s) prior to doing your builds but, depending on the number of triggers involved (and that it appears you're using a production database to conduct your builds), this may also be problematic.

2) You could also create a temporary table prior to doing your builds and modify your triggers to check for the existence of this table (the temporary table would always have the same name). If it exists, abort the trigger.

HTH...regards,

 

Mark

Comment
There are no comments made yet.
  • Page :
  • 1


There are no replies made for this question yet.
However, you are not allowed to reply to this question.