StrataFrame Forum » StrataFrame Application Framework - V1 » Business Objects and Data Access (How do I?) » BUG: Another Peculiar Behaviour

BUG: Another Peculiar Behaviour

Alagarsamy Rajamannar — Fri, 28 Dec 2007 10:35:38 GMT

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.

RE: BUG: Another Peculiar Behaviour

Greg McGuffey — Fri, 28 Dec 2007 10:35:38 GMT

Glad it worked. :D

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...

RE: BUG: Another Peculiar Behaviour

Alagarsamy Rajamannar — Fri, 28 Dec 2007 09:15:02 GMT

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

RE: BUG: Another Peculiar Behaviour

Greg McGuffey — Thu, 27 Dec 2007 14:00:01 GMT

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.

RE: BUG: Another Peculiar Behaviour

Alagarsamy Rajamannar — Thu, 27 Dec 2007 10:32:55 GMT

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

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]

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

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

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

RE: BUG: Another Peculiar Behaviour

Bill Cunnien — Thu, 27 Dec 2007 09:46:10 GMT

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