Hi,

 public partial class frmQuestionSections : MicroFour.StrataFrame.UI.Windows.Forms.StandardForm{

public frmQuestionSections(){

InitializeComponent();

questionSections1.FillAll();}

private void questionSections1_SetDefaultValues(){

questionSections1.BeneficiaryQuestionSectionID = Guid.NewGuid();}

}

As you can see the above code snippet keeps bombarding the same stored procedure for n times and finally throws stack overflow after 20 mins.

I have attached the debug.html file. You can see by yourself. I do not know why.

Please help me.

Have you tried placing the questionSections1.FillAll() method in the form's load event rather than the constructor?

Hi,

 FillAll is not a problem. Only when we edit and save , the updating stored procedure keeps bombarding.

 Note: The data gets updated and new records can inserted.

 I put a break point @ AfterSave Event.  It never fired.

 I uninstall the whole strataframe and re-installed

 I created another application and started from the scratch.

 This is the stored procedure I am using: 

CREATE PROCEDURE [dbo].[UpdateBeneficiaryQuestionSections]

@BeneficiaryQuestionSectionID uniqueidentifier,

@BeneficiaryQuestionSectionCode nchar(3),

@BeneficiaryQuestionSectionName nvarchar(50),

@BeneficiaryTypeID uniqueidentifier,

@BeneficiaryQuestionSectionID_ORGPK uniqueidentifier

AS

BEGIN

SET NOCOUNT ON

UPDATE [dbo].[BeneficiaryQuestionSections]

SET [BeneficiaryQuestionSectionCode] = @BeneficiaryQuestionSectionCode,

[BeneficiaryQuestionSectionName] = @BeneficiaryQuestionSectionName,

[BeneficiaryTypeID] = @BeneficiaryTypeID

WHERE [BeneficiaryQuestionSectionID]=@BeneficiaryQuestionSectionID

and

This is the table

CREATE TABLE [dbo].[BeneficiaryQuestionSections](

[BeneficiaryQuestionSectionID] [uniqueidentifier] NOT NULL CONSTRAINT [DF_BeneficiaryQuestionSections_BeneficiaryQuestionSectionID] DEFAULT (newid()),

[BeneficiaryQuestionSectionName] [nvarchar](50) NULL,

[BeneficiaryQuestionSectionCode] [nchar](3) NOT NULL,

[BeneficiaryTypeID] [uniqueidentifier] NULL,

CONSTRAINT [PK_BeneficiaryQuestionSections] PRIMARY KEY CLUSTERED

(

[BeneficiaryQuestionSectionID] ASC

)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]

) ON [PRIMARY]

GO

ALTER TABLE [dbo].[BeneficiaryQuestionSections] WITH CHECK ADD CONSTRAINT [FK_BQBeneficiaryTypeID] FOREIGN KEY([BeneficiaryTypeID])

REFERENCES [dbo].[BeneficiaryType] ([BeneficiaryTypeID])

GO

ALTER TABLE [dbo].[BeneficiaryQuestionSections] CHECK CONSTRAINT [FK_BQBeneficiaryTypeID]

I'm wondering if the SET NOCOUNT ON statement in the sproc is what's causing problems. In most cases SF is looking for some type of return that the update succeeded. I'm wondering if they are using the record count returned by ADO.NET and doing a retry if that is returned as zero, which would explain the behavior. I'd give that a try.



Otherwise, you'll likely have to wait for Ben/Trent to reply. There might be a bug and/or something different you have to do when using GUIDs. They might be out this week (based on the number of their posts...0). In which case, just bump this question up when you see them posting again.

REMOVING SET NOCOUNT ON WORKED FINE.

IF THAT IS THE CASE THEN IT SEEMS THAT WE SHOULD NOT HAVE SET NOACCOUNT ON

THANKS FOR YOUR REPLY

Glad it worked.



I'm thinking there might be a bug in SF though, as it went into an infinite loop. Seems like a exception should just be thrown or something...