Check-in Problems -- FailDBInsert()

[loutland]

Have been using Fortress successfully for awhile now but recently began receiving the following error messages from clients when attempting to check in any file. I am not an expert, so I will need instructions if I need to provide any additional information, such as server-side logs.

[6/28/2009 8:12:11 PM] Transaction failed
[6/28/2009 8:12:10 PM] An error occurred while trying to end a transaction.
[6/28/2009 8:12:10 PM] Transaction failed
[6/28/2009 8:12:10 PM] Item $/Admin/Customer Accounts/BartonCCC/SIWEPOVTG.orb caused the transaction to fail: A database error has occured (FailDBInsert)

I have re-verified permissions and everything seems fine. This used to work perfectly but this error recently began and it occurs regardless of file. Check out seems to work fine.

Both client and server are version 1.1.4.18402. The server is Windows 2008 Server and SQL Server 2008. Nothing has been changed configuration-wise except Windows updates have been applied as released by Microsoft.

Please advise.

[Beth]

The log that will tell us more about the issue will be the Vault Server Log found at C:\Windows\temp\sgvault\sgvault.log. Can you post the log? Once we are finished troubleshooting, then you can remove the log. Or, if you prefer, you can email it to me at support at sourcegear.com (attn: Beth) with a link to this forum thread.

[loutland]

The log is attached. After reviewing the log, it seems the problem is with the file date on the file being checked in. You see, we use a licensing package that sets the files to bad values. In the past this has not been a problem because SourceSafe had an option to set the file date to the check-in date. It does not appear that Fortress has this option, so I'm not sure what to do. These files are generated by a licensing system over which we have no control and we can't change what they do with the license files -- and we surely need them to be in Fortress.

I verified that check-in/out works properly with other files, such as source code and/or documents. So this problem seems to be related to these ORB or license files, which are binary and have invalid modification dates.

Please advise.

Thanks,

Lon Outland

********************************************************
----6/28/2009 6:40:28 PM sgvaultsystem--()--
System Started
Version 1.1.4.18402
Cache Level = 1
DataBase Buffer Size (KB) = 256
LogFile Path = C:\Windows\Temp\sgvault
Log Level = Quiet
Archive Log = Weekly
ReverseDNS Lookup = True
Maximum HTTP Request Length = 1024000
Overwrite Log on Startup = False
Session Timeout = 4320
SGVault Working Directory = C:\Windows\Temp
SGVault Server URL = https//vusource.gotdns.com
Identity = NT AUTHORITY\NETWORK SERVICE
----6/28/2009 6:40:34 PM loutland--::1(::1)--SSL Enabled Login
----6/28/2009 6:40:42 PM loutland--::1(::1)--SSL Enabled Logout
----6/28/2009 7:52:40 PM loutland--::1(::1)--SSL Enabled Login
----6/28/2009 7:52:49 PM loutland--::1(::1)--SSL Enabled Logout
----6/28/2009 7:52:55 PM loutland--::1(::1)--SSL Enabled Login
----6/28/2009 7:53:07 PM loutland--::1(::1)--SSL Enabled Logout
----6/28/2009 8:11:30 PM loutland--192.168.10.1(192.168.10.1)--SSL Enabled Login
----6/28/2009 8:11:44 PM loutland--192.168.10.1(192.168.10.1)--SSL Enabled System.Data.SqlTypes.SqlTypeException: SqlDateTime overflow. Must be between 1/1/1753 12:00:00 AM and 12/31/9999 11:59:59 PM.
at System.Data.SqlTypes.SqlDateTime.FromTimeSpan(TimeSpan value)
at System.Data.SqlTypes.SqlDateTime.FromDateTime(DateTime value)
at System.Data.SqlClient.MetaType.FromDateTime(DateTime dateTime, Byte cb)
at System.Data.SqlClient.TdsParser.WriteValue(Object value, MetaType type, Byte scale, Int32 actualLength, Int32 encodingByteSize, Int32 offset, TdsParserStateObject stateObj)
at System.Data.SqlClient.TdsParser.TdsExecuteRPC(_SqlRPC[] rpcArray, Int32 timeout, Boolean inSchema, SqlNotificationRequest notificationRequest, TdsParserStateObject stateObj, Boolean isCommandProc)
at System.Data.SqlClient.SqlCommand.RunExecuteReaderTds(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, Boolean async)
at System.Data.SqlClient.SqlCommand.RunExecuteReader(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, String method, DbAsyncResult result)
at System.Data.SqlClient.SqlCommand.InternalExecuteNonQuery(DbAsyncResult result, String methodName, Boolean sendToPipe)
at System.Data.SqlClient.SqlCommand.ExecuteNonQuery()
at VaultServiceSQL.VaultSqlSCC.CheckInFileInfo(VaultSqlConn conn, Int32 nRepID, Int64 nObjID, Int64 nFileLength, Int64 nForwardDeltaLength, Int64 nFullDeltaLength, UInt32 nFileCRC, VaultDateTime dtMod, Int64 nTxID, Int32 nTxItem, String strItemPath, String strComment, Boolean bAlreadyModifiedInTx, Int64& nObjVerID, Int64& nObjVersion, Int32& nMergeable, Int32& eol, Byte[]& forwardDeltafileptr, Byte[]& fullDeltafileptr) at System.Data.SqlTypes.SqlDateTime.FromTimeSpan(TimeSpan value)
at System.Data.SqlTypes.SqlDateTime.FromDateTime(DateTime value)
at System.Data.SqlClient.MetaType.FromDateTime(DateTime dateTime, Byte cb)
at System.Data.SqlClient.TdsParser.WriteValue(Object value, MetaType type, Byte scale, Int32 actualLength, Int32 encodingByteSize, Int32 offset, TdsParserStateObject stateObj)
at System.Data.SqlClient.TdsParser.TdsExecuteRPC(_SqlRPC[] rpcArray, Int32 timeout, Boolean inSchema, SqlNotificationRequest notificationRequest, TdsParserStateObject stateObj, Boolean isCommandProc)
at System.Data.SqlClient.SqlCommand.RunExecuteReaderTds(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, Boolean async)
at System.Data.SqlClient.SqlCommand.RunExecuteReader(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, String method, DbAsyncResult result)
at System.Data.SqlClient.SqlCommand.InternalExecuteNonQuery(DbAsyncResult result, String methodName, Boolean sendToPipe)
at System.Data.SqlClient.SqlCommand.ExecuteNonQuery()
at VaultServiceSQL.VaultSqlSCC.CheckInFileInfo(VaultSqlConn conn, Int32 nRepID, Int64 nObjID, Int64 nFileLength, Int64 nForwardDeltaLength, Int64 nFullDeltaLength, UInt32 nFileCRC, VaultDateTime dtMod, Int64 nTxID, Int32 nTxItem, String strItemPath, String strComment, Boolean bAlreadyModifiedInTx, Int64& nObjVerID, Int64& nObjVersion, Int32& nMergeable, Int32& eol, Byte[]& forwardDeltafileptr, Byte[]& fullDeltafileptr)
----6/28/2009 8:11:44 PM loutland--192.168.10.1(192.168.10.1)--SSL Enabled Rolling Back a transaction at VaultServiceSQL.VaultSqlConn.RollbackTransaction()
at VaultServiceAPILib.VaultServiceAPI.EndTx(Int32 nTxUserID, String strTxID, Int32 nTxAction, VaultIntTx vit, VaultDateTime& dtTxBegin, Int64& nNewRevision, VaultResponseItem[]& responses, VaultRepository& repNew)
at VaultService.VaultService.EndTx(String strTxID, Int32 nTxAction, VaultDateTime& dtTxBegin, Int64& nNewRevision, VaultResponseItem[]& responses)
at System.RuntimeMethodHandle._InvokeMethodFast(Object target, Object[] arguments, SignatureStruct& sig, MethodAttributes methodAttributes, RuntimeTypeHandle typeOwner)
at System.RuntimeMethodHandle.InvokeMethodFast(Object target, Object[] arguments, Signature sig, MethodAttributes methodAttributes, RuntimeTypeHandle typeOwner)
at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture, Boolean skipVisibilityChecks)
at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)
at System.Web.Services.Protocols.LogicalMethodInfo.Invoke(Object target, Object[] values)
at System.Web.Services.Protocols.WebServiceHandler.Invoke()
at System.Web.Services.Protocols.WebServiceHandler.CoreProcessRequest()
at System.Web.Services.Protocols.SyncSessionlessHandler.ProcessRequest(HttpContext context)
at System.Web.HttpApplication.CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()
at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)
at System.Web.HttpApplication.PipelineStepManager.ResumeSteps(Exception error)
at System.Web.HttpApplication.BeginProcessRequestNotification(HttpContext context, AsyncCallback cb)
at System.Web.HttpRuntime.ProcessRequestNotificationPrivate(IIS7WorkerRequest wr, HttpContext context)
at System.Web.Hosting.PipelineRuntime.ProcessRequestNotificationHelper(IntPtr managedHttpContext, IntPtr nativeRequestContext, IntPtr moduleData, Int32 flags)
at System.Web.Hosting.PipelineRuntime.ProcessRequestNotification(IntPtr managedHttpContext, IntPtr nativeRequestContext, IntPtr moduleData, Int32 flags)
at System.Web.Hosting.UnsafeIISMethods.MgdIndicateCompletion(IntPtr pHandler, RequestNotificationStatus& notificationStatus)
at System.Web.Hosting.PipelineRuntime.ProcessRequestNotificationHelper(IntPtr managedHttpContext, IntPtr nativeRequestContext, IntPtr moduleData, Int32 flags)
at System.Web.Hosting.PipelineRuntime.ProcessRequestNotification(IntPtr managedHttpContext, IntPtr nativeRequestContext, IntPtr moduleData, Int32 flags)

----6/28/2009 8:11:44 PM loutland--192.168.10.1(192.168.10.1)--SSL Enabled (d914cda6-f153-4bbe-bd0f-88801b93733a) EndTx (Revision - 0) returned: FailDBInsert
----6/28/2009 8:11:44 PM loutland--192.168.10.1(192.168.10.1)--SSL Enabled (d914cda6-f153-4bbe-bd0f-88801b93733a) CheckIn: $/Admin/Customer Accounts/BartonCCC/SIWEPOVTG.orb returned: FailDBInsert
**************************************************

[Beth]

SqlDateTime overflow. Must be between 1/1/1753 12:00:00 AM and 12/31/9999 11:59:59 PM.

I think this error indicates something with .NET. Even if you were checking in with the modification time instead of the check in time, this error shouldn't come up.

You see, we use a licensing package that sets the files to bad values.

How do you mean? If some other application is giving the file bad dates, then it would make sense that it can't check in.

SourceSafe had an option to set the file date to the check-in date. It does not appear that Fortress has this option,

On check-out, both can set the file date to current, modification, or check-in. On check-in, there isn't a file date set for either. The modification and check-in times are both captured.

I have no other reports of problems with license files, and you say it works under SourceSafe. I think we should pursue looking at this as a .NET framework issue. Do you have any errors in your Event Viewer logs that coincide with the problems you have checking in?

Do all clients have the same issue or just a limited number?

[loutland]

What I mean is that we use a licensing package to edit license files (which are in Fortress -- we check them out, modify them with the licensing package, but are then unable to check them back in because when the licensing program saves the files to disk, the modification time/date on the file is set to a range outside that stated in the error message).

Before, SourceSafe had an option on the check in dialog that, when selected, SourceSafe would update the file date/time of the checked out file to be the date/time of checkin. I suspect that's how we avoided this problem before -- that is, SourceSafe would "touch" the modified/checked-out file before performing the check-in so that the file modification date/time was set to the current date/time.

I don't know if it's a .NET issue or not. The problem occurs on all clients that I have checked. We only have 4 clients and I have checked two of them. Both are showing the same problem. The only thing running on this server is Fortress and all Windows updates have been applied, so I don't know what the .NET problem could be. As I said before, the problem does not happen with other files -- only these license files, but SourceSafe handled them fine.

[jeremy_sg]

I'm sorry, but I'm not finding the option in SourceSafe that would do that. Could you please point me to it?

Vault was written to respect the modified time of the file, and store it in the Vault database. We can fix the server so it ignores any dates that are outside SQL's range, but it would be a few weeks before such a change would be released in Vault 5.0. In the meantime, would you consider running a batch file that corrected the modification times on these files after your licensing package changes them?

[loutland]

Is there a way to automate the batch file run so that it happens automatically (i.e., executed as part of the check-in) or is this something that would need to be done manually? I no longer have SourceSafe installed on my current laptop, so I can't point you to the option. However, I do know for absolute certain that these files were handled in VSS without problem -- we have used SourceSafe for the past 10 years or so without a problem. I am not sure whether VSS didn't care about the dates or whether it actually set them to the check-in date, but I do seem to recall an option regarding check-in dates. It is possible, however, that I'm mistaken and that VSS just ignored bad or out of range file modification information. If I can get my old laptop up and running and attach to a VSS database, I will see if I can point to what I was thinking of.

[loutland]

I was able to bring up VSS -- and I was mistaken. There is no option that I previously mentioned. However, I did look at some of the license files in VSS and they all had a 1970 date, which makes me think that VSS was defaulting them if they were out of range or something. Specifically, here's the date that showed in VSS for several of these files (I did not check them all):

1/1/70 33:00p

I think we definitely would like to see something other than "blowing up" when such files are checked in. This does not seem like very good behavior even though I understand that it's "not supposed to happen." Mimicking the behavior of VSS would certainly be acceptable.

Other than this issue, we have thus far been very impressed with Fortress. I suppose you have no plans to release a MAC/Java client at some point do you? The web interface seems somewhat limited.

Thanks,

[jeremy_sg]

What date does the file on disk have? Would you be willing to run a command line script to correct the date?

I've logged this bug a f14583, and I'll make sure it gets fixed for the 5.0 release.

[loutland]

I suppose that's possible, but it is a short term solution unless we can somehow cause the script to be executed automatically with the check-in process. I assume that the latter is not possible. For the short term, we could use a windows version of the unix touch command. I would like to be notified when the new version of Fortress is ready. Is there a timeframe?

[jeremy_sg]

The timeframe for the actual release is less than a month. You can get updates for releases by following the rss feed of the Release Notes forum. See:

http://support.sourcegear.com/viewtopic ... 4252#p4252