Sage 100

Starship / SQL question. Today marked the end of several days of troubleshooting an extreme system slowdown on v2015 Premium that happened daily at 11:15am that required a daily reboot of the server (which has both App Server and SQL, as well as many 3rd party apps, and some IT mgmt tools). Not a Sage issue. I worked with IT to do all kinds of troubleshooting and in the process Sage and the system run much spiffier, much more stable, and shored up several other IT and Sage issues along the way. However none of that good news resolved the daily 11:15am saga until today. Below I have purposely transposed the the back-slashes to forward slashes b/c the double backslash does not appear: In SQL for the Starship database: DB Name = Starship, Logical Name = SSParcel, physical file name = D:/MSSQL/Data/Starship.mdf *** For the Starship Transaction Log: Logical Name = SSParcel_log, **physical file name = E:/MSSQL/Data//Starship.LDF** Correcting the Trans Log physical file name to use a \ (single backslash) fixed the 11:15 issue. I guess it was trying to write to the Trans Log LDF file but could not and it locked-up the server in a bad way. Surprisingly it never showed an error (not in any log file I looked at) and the Profiler traces I took didn't capture this. _Has anyone else seen this with SQL version of Starship?_ Just trying to figure out if this is how Starship normally gets installed OR somebody changed it to be like this.

I want to follow this. Is this an append to the transaction log, a simple, etc? Is there a timeout that can be set to abort the transaction log insert?

I edited post to use forward slashes b/c it looks like on SocialCast you can't make a double-backslash appear so at least now problem is described correctly. Doug I assume Starship was INSERTing rows. Timeout depends on the connection method. E.g. if Starship uses OLEDB it can specify timeout value itself in the connection string. If it doesn't, it uses Remote Query Timeout value that's found in SSMS under the server properties in the Connections node which defaults to 600 seconds (10 minutes) which sounds about right for the client. For that client of yours who uses Starship SQL, I'm curious to know if in SSMS under Starship DB, under Files, if you see the path to Starship.mdf with double backslashes too. One other mildly interesting note is we are on SQL 2014 SP2 Std 64-bit but Starship DB compatibility level = 2008.

Am I looking in the correct place? Right click on the database ""Starship"", Properties, Files. The path and the file names are in separate fields. This is SQL 2012.

Sorry Doug. Run it like this instead: ` SELECT name, physical_name AS current_file_location ` ` FROM sys.master_files `

My example uses the default ""Starship"" as the database name, and unfortunately do not see the double backslash issue you experienced. I wonder if someone tried to rename the database, the mdf and ldf file names. They may have used an ALTER DATABASE and inadvertently added a extra backslash to the path. If that is the case then it would seem to be a bug in the T-SQL interpreter.

Thanks for checking Doug! The default ""Starship"" probably means your client has LTL version and mine has Parcel. In researching it looks like double backslashes in the physical filename has happened to other people in the non-Sage SQL world if the system databases were installed with 2 backslashes at the end (e.g. the Master or Model db) when SQL Server was installed. But in this case it was limited to Starship. But also read the 2 backslashes causes big issues with Backup programs which makes a lot more sense than Starship application itself causing this server lockup. Hmm I think the saga is not over.

Seems the poor performance might have been a good fortune. It alerted you to the issue writing to the log file. If the log file wasn't getting written to then recovery from a backup would be compromised.