Hi

The suggestion I made won't affect the generated classes at all as it doesn't touch them.  what it would do though is to alter the generated update PROC so that instead of producing:

CREATE PROCEDURE [proc_TestUpdate]
(
@ID int,
@ParentRef int = NULL,
@Name varchar(50) = NULL,
@RowGUID
)
AS

BEGIN
SET NOCOUNT OFF
DECLARE @Err int
UPDATE [AggregateTest]
SET
[ParentRef] = @ParentRef,
[Name] = @Name,
[RowGUID] = @RowGUID
WHERE
[ID] = @ID
SET @Err = @@Error
RETURN @Err
END

GO

It would (should as it's untested) produce:

CREATE PROCEDURE [proc_TestUpdate]
(
@ID int,
@ParentRef int = NULL,
@Name varchar(50) = NULL,
@RowGUID
)

AS

BEGIN
SET NOCOUNT OFF
DECLARE @Err int
UPDATE [AggregateTest]
SET
[ParentRef] = @ParentRef,
[Name] = @Name,
WHERE
[ID] = @ID
SET @Err = @@Error
RETURN @Err
END

GO

Notice that the RowGUID field is still listed in it's parameters but it isn't actually used in the update part - much the same as with the ID field.  Obviously it's far from ideal and to be frank, I would go with my first option (i.e. copying this table to a new table, removing the GUID fields and re-generating against that) but if you can't do that at this stage then this option, although a bit hacky, should do what you need as far as altering the SPROCs goes.

Hope that helps

Martin

Yepp, after some messing around with VbScript i was able to do so:

blnIgnore = False
		If objColumn.Properties.ContainsKey("IgnoreColumn") Then
			If objColumn.Properties.Item("IgnoreColumn") = "true" Then
				blnIgnore = true
			End If
		End If		

		If Not objColumn.IsInPrimaryKey And Not objColumn.IsAutoKey And Not objColumn.IsComputed And Not blnIgnore Then
		
[...]  

I can live with that for now, as it allows me to regenerate the sprocs as often i want to and i don´t have to worry they possibly don´t work. If we are sure we don´t do major changes anymore the copy-table option sure is far better. But maybe the ES-Team came up with something by that time

Thanks a lot again,

Joris 

I like that even more:

                blnIgnore = False
		If objColumn.Name = "rowguid" And objDatabase.Properties.ContainsKey("IgnoreRowGuid") Then
			If objDatabase.Properties.Item("IgnoreRowGuid") = "true" Then
				blnIgnore = true
			End If
		End If	

Cheers,

Joris 

Great

Glad you got it working.  I've just had another thought about the benefits of going down the copied table route in that, even though your sprocs are now altered for updates, your entities still have that field defined/exposed which in this case doesn't make much sense as it will never be used in your app. 

Naturally if you/another developer were to actually use the value then that would be different.  Depending on how many of these types of field there are (and how far down the customisation road you are with your Custom classes) I might be tempted to create a template to override those properties in your Custom classes and mark them as Obsolete or something so that they don't get used in error.  On the plus side, now that you know how to identify them using MyGeneration, looping through all of your tables/fields etc to do this shouldn't be too difficult.

I suppose though that it really depends on how likely it is that the table def will change over the development cycle and how many times (i.e. is it more cost effective for you to go the route you are now and thereby introduce 'dead properties' into the generated code, or for you to regen using the 'dummy' table each time you alter the table def). Personally I'd go down the dummy table route unless there were likely to be many many changes to the table def and I was concerned that I'd forget to make the copy and generate against that.

Anyway, better get on with some work!

Cheers

Martin

Who works here?

 At the moment we are only 2 Developers on that Project and i don´t think that will change for some time. Plus, i think i modify the template a little more so the INSERT-Proc ignores that column, too.

That way, even if someone has the idea to change the Property of the Entity prior to adding it, it won´t do any harm. The two of us have the customized template and if someone else runs a non-customized template to create the stored procedures in the database i would call that criminal intent, not likely to happen :).

To answer some of your questions: this column exists in every single table in the database so its far from being nice this way now. Its an unnecessary overhead right now but there´s no realistic chance it will do any harm right now, even performance is not really an issue, as database operations don´t occur that often and the database itself is still very very small.


I´ll definitely will use a dummy table some time in the future if there´s no other way. But now i´m glad i can click one button and don´t have to care i get calls about some Sql-Exception that occurs every time someone tests the application. 

Should really do some work now :)

 Bye,

Joris