Timestamp stored procedure issues.

Oct 21, 2007 at 7:13 PM
I ran in to an issue with timestamps.
Since you are not allowed to add timestamps as part of an insert, I had an issue were the insert and the update stored procedures weren't being created.

I fixed this by removing the timestamp as part of the insert/update, and tweaked the result select:

/****** Object: Stored Procedure CalendarInsert - Script Date: Sunday, October 21, 2007 ******/
if exists (select * from sysobjects where id = object_id(N'CalendarInsert') and OBJECTPROPERTY(id, N'IsProcedure') = 1)
drop procedure CalendarInsert
GO

SET QUOTED_IDENTIFIER ON
GO
SET ANSI_NULLS OFF
GO

/*------------------------------------------------------------------------
<generated>
This code was generated by The NuSoft Framework v2.0
Generated at 10/21/2007 1:54:46 PM.

The NuSoft Framework is an open source project developed
by NuSoft Solutions (http://www.nusoftsolutions.com).
The latest version of the framework templates and detailed license
is available at http://www.codeplex.com/NuSoftFramework.

This file will be overwritten when regenerating your code.
</generated>
------------------------------------------------------------------------*/

CREATE PROCEDURE CalendarInsert
@Name varchar(50),
@ts timestamp,
@d bit
AS

DECLARE @table TABLE(
CalendarID int,
Name varchar(50),
d bit
);

INSERT INTO dbo.Calendar (
Calendar.Name,
Calendar.d
)
output
INSERTED.CalendarID,
INSERTED.Name,
INSERTED.d
into @table
VALUES (
@Name,
ISNULL(@d, ((0)))
);

SELECT
CalendarID,
Name,
ts,
d
FROM dbo.Calendar
WHERE CalendarID = (SELECT TOP 1 CalendarID FROM @table);


GO

SET QUOTED_IDENTIFIER OFF
GO
SET ANSI_NULLS ON
GO
Coordinator
Mar 11, 2008 at 2:05 AM
CitizenBane,

I'm looking into trying to add timestamp support, but am curious as to what you would want to see. The easiest solution is to basically ignore it. We don't do anything with concurrency at the moment anyway, so it wouldn't be used by the framework anyway. Other frameworks use this approach as well (.NetTiers, I think).

The issue I'm running into is getting the updated timestamp back into the framework after the update - it doesn't come through in the inserted trigger tables, so it's not getting updated back in the entity anyway. So I was hoping to get a little feedback on how you use it, so I can make sure the implementation works well for you.

My instinct is saying to just not use the field altogether.
Mar 13, 2008 at 12:20 PM
Edited Mar 13, 2008 at 12:20 PM
Essentially, I was working on a smartclient that has a local store that syncs with an online database.
I was attempting to use the timestamps to keep track of which rows had a change since the last sync.

As of late, I've been focused on using NetTiers. I love the architecture, even though it may have a bit of a DRY problem (something that can be fixed with use of better generics).
A colleague of mine found out about the Micrsoft Sync Framework (http://msdn2.microsoft.com/en-us/sync/default.aspx) and the new features of SQL Server 2008 such as change tracking. He has already created a Microsoft SQL Server CE provider, and is in the process of creating the templates that would sync the two databases.