From gustav at cactus.dk Fri Jun 1 03:14:48 2012 From: gustav at cactus.dk (Gustav Brock) Date: Fri, 01 Jun 2012 10:14:48 +0200 Subject: [dba-SQLServer] SQL Server version info Message-ID: Hi all I had to identify a client's SQL Server version from the version number and located this comprehensive page for the purpose: http://sqlserverbuilds.blogspot.dk/ It claims to list every possible version from 7.0 Beta 3 to the current 2012 RTM. /gustav From jwcolby at colbyconsulting.com Tue Jun 5 06:36:22 2012 From: jwcolby at colbyconsulting.com (jwcolby) Date: Tue, 05 Jun 2012 07:36:22 -0400 Subject: [dba-SQLServer] OT: SAS / SATA standards explanation Message-ID: <4FCDEF36.6020403@colbyconsulting.com> This is a good read if you have always wondered... http://www.ioisas.com/about-sas.htm -- John W. Colby Colby Consulting Reality is what refuses to go away when you do not believe in it From jwcolby at colbyconsulting.com Tue Jun 5 20:38:12 2012 From: jwcolby at colbyconsulting.com (jwcolby) Date: Tue, 05 Jun 2012 21:38:12 -0400 Subject: [dba-SQLServer] Displaying SQL Server Time(7) in Access Message-ID: <4FCEB484.4080806@colbyconsulting.com> I am stumped on how to display a SQL Server time value in an Access form while leaving it editable. If I look directly in the table in SQL Server a time is displayed like this: 08:45:00.0000000. Likewise it is displayed in the Access form in that manner which of course is a major annoyance. Access input masks work correctly for stuffing the times in but "formats" such as Short time etc have no apparent effect at all. For reporting I can simply do a left(SomeTime,5) to get HH:MM format but of course I can't do that in the form's text field. So how the heck do I do this format in the form to display just the hour and minute? -- John W. Colby Colby Consulting Reality is what refuses to go away when you do not believe in it From jwcolby at colbyconsulting.com Tue Jun 5 21:14:06 2012 From: jwcolby at colbyconsulting.com (jwcolby) Date: Tue, 05 Jun 2012 22:14:06 -0400 Subject: [dba-SQLServer] Displaying SQL Server Time(7) in Access In-Reply-To: <4FCEB484.4080806@colbyconsulting.com> References: <4FCEB484.4080806@colbyconsulting.com> Message-ID: <4FCEBCEE.3050204@colbyconsulting.com> Ahh I figured it out. I had this working in the past. The key seems to be not using the time() format but rather using the DateTime format in SQL Server. Sorry for the ring. John W. Colby Colby Consulting Reality is what refuses to go away when you do not believe in it On 6/5/2012 9:38 PM, jwcolby wrote: > I am stumped on how to display a SQL Server time value in an Access form while leaving it editable. > If I look directly in the table in SQL Server a time is displayed like this: 08:45:00.0000000. > Likewise it is displayed in the Access form in that manner which of course is a major annoyance. > > Access input masks work correctly for stuffing the times in but "formats" such as Short time etc > have no apparent effect at all. For reporting I can simply do a left(SomeTime,5) to get HH:MM format > but of course I can't do that in the form's text field. > > So how the heck do I do this format in the form to display just the hour and minute? > From stuart at lexacorp.com.pg Tue Jun 5 22:15:24 2012 From: stuart at lexacorp.com.pg (Stuart McLachlan) Date: Wed, 06 Jun 2012 13:15:24 +1000 Subject: [dba-SQLServer] Displaying SQL Server Time(7) in Access In-Reply-To: <4FCEBCEE.3050204@colbyconsulting.com> References: <4FCEB484.4080806@colbyconsulting.com>, <4FCEBCEE.3050204@colbyconsulting.com> Message-ID: <4FCECB4C.21719.23FE0BCF@stuart.lexacorp.com.pg> I seem to recall having the same discussion about a year ago where we identified the problem with the new SQL Server Date and Time types and ODBC returning them as strings :-) -- Stuart On 5 Jun 2012 at 22:14, jwcolby wrote: > Ahh I figured it out. I had this working in the past. The key seems to be not using the time() > format but rather using the DateTime format in SQL Server. > > Sorry for the ring. > > John W. Colby > Colby Consulting > > Reality is what refuses to go away > when you do not believe in it > > On 6/5/2012 9:38 PM, jwcolby wrote: > > I am stumped on how to display a SQL Server time value in an Access form while leaving it editable. > > If I look directly in the table in SQL Server a time is displayed like this: 08:45:00.0000000. > > Likewise it is displayed in the Access form in that manner which of course is a major annoyance. > > > > Access input masks work correctly for stuffing the times in but "formats" such as Short time etc > > have no apparent effect at all. For reporting I can simply do a left(SomeTime,5) to get HH:MM format > > but of course I can't do that in the form's text field. > > > > So how the heck do I do this format in the form to display just the hour and minute? > > > > _______________________________________________ > dba-SQLServer mailing list > dba-SQLServer at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/dba-sqlserver > http://www.databaseadvisors.com > > -- Stuart McLachlan Ph: +675 340 4392 Mob: +675 7100 2028 Web: http://www.lexacorp.com.pg From jwcolby at colbyconsulting.com Tue Jun 5 22:48:56 2012 From: jwcolby at colbyconsulting.com (jwcolby) Date: Tue, 05 Jun 2012 23:48:56 -0400 Subject: [dba-SQLServer] Displaying SQL Server Time(7) in Access In-Reply-To: <4FCECB4C.21719.23FE0BCF@stuart.lexacorp.com.pg> References: <4FCEB484.4080806@colbyconsulting.com>, <4FCEBCEE.3050204@colbyconsulting.com> <4FCECB4C.21719.23FE0BCF@stuart.lexacorp.com.pg> Message-ID: <4FCED328.6020909@colbyconsulting.com> I know! My memory is getting really bad. I knew that was the problem but when I made the change (in SQL Server) it didn't help. It turns out that my framework was determining that the control's data source was a date and putting in a date format string. Once I stopped that it all started working. John W. Colby Colby Consulting Reality is what refuses to go away when you do not believe in it On 6/5/2012 11:15 PM, Stuart McLachlan wrote: > I seem to recall having the same discussion about a year ago where we identified the > problem with the new SQL Server Date and Time types and ODBC returning them as strings > :-) > From gustav at cactus.dk Wed Jun 6 06:48:45 2012 From: gustav at cactus.dk (Gustav Brock) Date: Wed, 06 Jun 2012 13:48:45 +0200 Subject: [dba-SQLServer] Displaying SQL Server Time(7) in Access Message-ID: Hi John "Stopped all that"? So now you handle your date values as strings? Oh my ... And a "time() format" ... what is that? Unless you need the submillisecond resolution SQL Server data type DateTime2 offers, all you need is to change the data type (not a format) of the field in SQL Server to good old DateTime. Then your framework will run unmodified. It was Feb. 17th you fought with this the last time. /gustav >>> jwcolby at colbyconsulting.com 06-06-12 5:48 >>> I know! My memory is getting really bad. I knew that was the problem but when I made the change (in SQL Server) it didn't help. It turns out that my framework was determining that the control's data source was a date and putting in a date format string. Once I stopped that it all started working. John W. Colby Colby Consulting Reality is what refuses to go away when you do not believe in it On 6/5/2012 11:15 PM, Stuart McLachlan wrote: > I seem to recall having the same discussion about a year ago where we identified the > problem with the new SQL Server Date and Time types and ODBC returning them as strings > :-) From jwcolby at colbyconsulting.com Wed Jun 6 07:01:37 2012 From: jwcolby at colbyconsulting.com (jwcolby) Date: Wed, 06 Jun 2012 08:01:37 -0400 Subject: [dba-SQLServer] Displaying SQL Server Time(7) in Access In-Reply-To: References: Message-ID: <4FCF46A1.3010700@colbyconsulting.com> Gustav, > "Stopped all that"? I do so little Access these days and even less Access with SQL Server that I really don't keep current on it. Because my framework is "bound" it can drill down to discover the data type of every control on a (bound) form. I then built stuff in the framework (years ago) to "standardize" handling dates by inserting a fixed format string (for display) and input mask (for data entry). All of that is automatic unless I over-ride it, which can be nice since I can apply a standard to every form that the framework manages for me without having to find and fix these properties manually. Thus part of my problem was that I used the time(7) date type in SQL Server, but even after fixing that by moving back to the DateTime in SQL Server my framework was still applying a *date* format and data entry string to the controls on these forms. I had placed the format and input masks I wanted in the control properties but the framework was helpfully "standardizing" them for me back to "date". Once I told the framework not to do that the problem was solved. John W. Colby Colby Consulting Reality is what refuses to go away when you do not believe in it On 6/6/2012 7:48 AM, Gustav Brock wrote: > Hi John > > "Stopped all that"? > So now you handle your date values as strings? Oh my ... > > And a "time() format" ... what is that? > > Unless you need the submillisecond resolution SQL Server data type DateTime2 offers, all you need is to change the data type (not a format) of the field in SQL Server to good old DateTime. Then your framework will run unmodified. > > It was Feb. 17th you fought with this the last time. > > /gustav > From stuart at lexacorp.com.pg Wed Jun 6 07:03:34 2012 From: stuart at lexacorp.com.pg (Stuart McLachlan) Date: Wed, 06 Jun 2012 22:03:34 +1000 Subject: [dba-SQLServer] Displaying SQL Server Time(7) in Access In-Reply-To: References: Message-ID: <4FCF4716.1378.25E19997@stuart.lexacorp.com.pg> And it was 18 June 2011 when he fought with it the first time. At that time I posted this: ------------------------------------------------------------------------- http://msdn.microsoft.com/en-us/library/ms180878.aspx#ODBCDatetimeFormat Backward Compatibility for Down-level Clients Some down-level clients do not support the time, date, datetime2 and datetimeoffset data types added in SQL Server 2008. The following table shows the type mapping between an up-level instance of SQL Server 2008 and down-level clients. Looks like you are using one of SQL Server 2008's new date/time data types for that field and accessing it via ODBC. MS in their wisdom have decided to convert it and return a YY-MM-DD string instead of a numeric value of some type. Best bet is to change the field type in SQL Server to one of the older datetime or smalldatetime types. ------------------------------------------------------------------------- Guess some people never learn :-) -- Stuart On 6 Jun 2012 at 13:48, Gustav Brock wrote: > > It was Feb. 17th you fought with this the last time. > > /gustav > > -- Stuart McLachlan Ph: +675 340 4392 Mob: +675 7100 2028 Web: http://www.lexacorp.com.pg From jwcolby at colbyconsulting.com Wed Jun 6 07:11:10 2012 From: jwcolby at colbyconsulting.com (jwcolby) Date: Wed, 06 Jun 2012 08:11:10 -0400 Subject: [dba-SQLServer] Displaying SQL Server Time(7) in Access In-Reply-To: <4FCF4716.1378.25E19997@stuart.lexacorp.com.pg> References: <4FCF4716.1378.25E19997@stuart.lexacorp.com.pg> Message-ID: <4FCF48DE.7010100@colbyconsulting.com> LOL, it ain't about learning, it is about remembering. John W. Colby Colby Consulting Reality is what refuses to go away when you do not believe in it On 6/6/2012 8:03 AM, Stuart McLachlan wrote: > And it was 18 June 2011 when he fought with it the first time. At that time I posted this: > > ------------------------------------------------------------------------- > http://msdn.microsoft.com/en-us/library/ms180878.aspx#ODBCDatetimeFormat > > > Backward Compatibility for Down-level Clients > > Some down-level clients do not support the time, date, datetime2 and > datetimeoffset data types added in SQL Server 2008. The following table > shows the type mapping between an up-level instance of SQL Server 2008 and > down-level clients. > > Looks like you are using one of SQL Server 2008's new date/time data types > for that field and accessing it via ODBC. MS in their wisdom have > decided to convert it and return a YY-MM-DD string instead of a numeric > value of some type. > > Best bet is to change the field type in SQL Server to one of the older > datetime or smalldatetime types. > ------------------------------------------------------------------------- > > > Guess some people never learn :-) > From gustav at cactus.dk Wed Jun 6 07:29:30 2012 From: gustav at cactus.dk (Gustav Brock) Date: Wed, 06 Jun 2012 14:29:30 +0200 Subject: [dba-SQLServer] Displaying SQL Server Time(7) in Access Message-ID: Hi Stuart Hmmm ... for my part I will certainly not claim to be able to remember everything I have done or written. I search a lot to find my old gold nuggets! /gustav >>> stuart at lexacorp.com.pg 06-06-12 14:03 >>> And it was 18 June 2011 when he fought with it the first time. .. From jwcolby at colbyconsulting.com Wed Jun 6 09:14:12 2012 From: jwcolby at colbyconsulting.com (jwcolby) Date: Wed, 06 Jun 2012 10:14:12 -0400 Subject: [dba-SQLServer] Displaying SQL Server Time(7) in Access In-Reply-To: References: Message-ID: <4FCF65B4.6010503@colbyconsulting.com> Part of my problem is that I have never gotten good at using our archives for finding things. John W. Colby Colby Consulting Reality is what refuses to go away when you do not believe in it On 6/6/2012 8:29 AM, Gustav Brock wrote: > Hi Stuart > > Hmmm ... for my part I will certainly not claim to be able to remember everything I have done or written. I search a lot to find my old gold nuggets! > > /gustav > > >>>> stuart at lexacorp.com.pg 06-06-12 14:03>>> > And it was 18 June 2011 when he fought with it the first time. .. > > _______________________________________________ > dba-SQLServer mailing list > dba-SQLServer at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/dba-sqlserver > http://www.databaseadvisors.com > > From jwcolby at colbyconsulting.com Wed Jun 6 12:08:42 2012 From: jwcolby at colbyconsulting.com (jwcolby) Date: Wed, 06 Jun 2012 13:08:42 -0400 Subject: [dba-SQLServer] SQL Server Encrypted field Message-ID: <4FCF8E9A.8060201@colbyconsulting.com> I need to store sensitive data in specific fields of specific tables. I find things like: http://msdn.microsoft.com/en-us/library/ms179331.aspx Which discusses creating a certificate etc. Hmm... what happens if the database is backed up? What happens if I need to move the database? And of course my favorite SQL guy (Pinal Dave): http://blog.sqlauthority.com/2009/04/28/sql-server-introduction-to-sql-server-encryption-and-symmetric-key-encryption-tutorial-with-script/ In the end however what I want do (in this case) is to allow specific information to be encrypted / decrypted on a user specific basis, i.e. based on something user specific. Assume that users need to store their own Email Address, username and password in my database and then use that to send email "on their behalf" from my system. The database is used for generating Community Volunteer passes, and when the pass is created it is printed to PDF, attached to an email and mailed to one or more email address at a specific prison. I have created a new GMail account with a username and password but it would be nice to allow each user to enter their own email address / username / password to send from so that if there are issues and the prison replies to the email, it gets back to them directly. Using my current system it would come back to my general address. Of course I can do a "do not respond to this email" kind of thing but I have already been asked if they can get responses. Obviously if I am going to store a user's email address, username and password it has to be encrypted, but furthermore it has to be retrievable only by that user. -- John W. Colby Colby Consulting Reality is what refuses to go away when you do not believe in it From fuller.artful at gmail.com Wed Jun 6 18:10:06 2012 From: fuller.artful at gmail.com (Arthur Fuller) Date: Wed, 6 Jun 2012 19:10:06 -0400 Subject: [dba-SQLServer] Seriously, I don't make this stuff up: The City of Dull twins her sister, The City of Boring. I do not make this stuff up! Message-ID: This may not be the most interesting news in the world, but that?s actually what this story has going for it. In a brilliant example of people with the ability to laugh at themselves, the city of Dull in Scotland may become official partners with Boring, Oregon. A woman cycling through Scotland had the idea and decided to contact her friend Emma Burtles, who lives in Dull. Burtles decided to contact the Boring Community Planning Organization. -- Arthur Cell: 647.710.1314 Only two businesses describe their clients as Users: drug-dealing and sofrware development. Think about that, if only for a moment. -- Arthur Fuller From stephen at bondsoftware.co.nz Thu Jun 7 14:21:05 2012 From: stephen at bondsoftware.co.nz (Stephen Bond) Date: Fri, 08 Jun 2012 07:21:05 +1200 Subject: [dba-SQLServer] OT (it's Friday down here in the Antipodes): Dull and Boring Message-ID: Arthur We have good friends from college days in Oregon who live in Boring. They tell me Dull and Boring are now "twinned" -- the Boring Community group approved the relationship at their meeting Tuesday night. Our friends are visiting Dull in the Fall. In the '60s we all went to college in the wettest part of Oregon, just north of a town called Drain. There must be a town somewhere looking for a mate? Hole-in-the-Floor? New Zealand place-names are so colourless (boring?). Stephen Bond From gustav at cactus.dk Fri Jun 8 08:08:43 2012 From: gustav at cactus.dk (Gustav Brock) Date: Fri, 08 Jun 2012 15:08:43 +0200 Subject: [dba-SQLServer] Trigger syntax Message-ID: Hi all I'm new to triggers but I've managed to create this which works as intended: USE [PPT] GO /****** Object: Trigger [dbo].[T_VariantsTable_UTrig] Script Date: 06/08/2012 14:45:17 ******/ SET ANSI_NULLS ON GO SET QUOTED_IDENTIFIER ON GO -- ============================================================= -- Author: Gustav Brock -- Create date: 2012-06-08 -- Description: Update field Created to time of update of record -- ============================================================= ALTER TRIGGER [dbo].[T_VariantsTable_UTrig] ON [dbo].[VariantsTable] FOR UPDATE AS BEGIN -- SET NOCOUNT ON added to prevent extra result sets from -- interfering with SELECT statements. SET NOCOUNT ON; -- Insert statements for trigger here DECLARE @id INT DECLARE @now DATETIME -- Retrieve ID of changed record. SELECT @id = (SELECT ID FROM deleted) -- Get current time without milliseconds. SELECT @now = DATEADD(SECOND, DATEDIFF(SECOND, '20000101', GETDATE()), '20000101') UPDATE VariantsTable SET Changed = @now WHERE ID = @id END However, when I open this in SMMS, this line has the last part red underlined: ALTER TRIGGER [dbo].[T_VariantsTable_UTrig] stating: Invalid object name 'dbo.T_VariantsTable_UTrig' Why is that? I have another trigger created by the Access upsize wizard with similar code: ALTER TRIGGER [dbo].[T_VariantsTable_ITrig] and nothing is underlined here. /gustav From gustav at cactus.dk Fri Jun 8 09:44:12 2012 From: gustav at cactus.dk (Gustav Brock) Date: Fri, 08 Jun 2012 16:44:12 +0200 Subject: [dba-SQLServer] Random autonumber ID Message-ID: Hi all I'm working on upsizing an Access backend to SQL Server and used Access' wizard for this. That worked with no errors. However, the client used Random Autonumber for IDs in Access and these are converted to integer with an associated trigger to create the random ID for new records: USE [PPT] GO /****** Object: Trigger [dbo].[T_UserLastDataTable_ITrig] Script Date: 06/08/2012 16:19:49 ******/ SET ANSI_NULLS ON GO SET QUOTED_IDENTIFIER ON GO ALTER TRIGGER [dbo].[T_UserLastDataTable_ITrig] ON [dbo].[UserLastDataTable] FOR INSERT AS SET NOCOUNT ON DECLARE @randc int, @newc int /* EMULATION CODE FOR AUTONUMBERING */ /* * EMULATION CODE FOR RANDOM AUTONUMBERING FOR FIELD "ID" */ SELECT @randc = (SELECT convert(int, rand() * power(2, 30))) SELECT @newc = (SELECT ID FROM inserted) UPDATE UserLastDataTable SET ID = @randc WHERE ID = @newc Is this really the best method? Any disadvantages? Would we be better off changing ID in Access to either sequential IDs or even GUID before running the update wizard? /gustav From fuller.artful at gmail.com Fri Jun 8 10:20:00 2012 From: fuller.artful at gmail.com (Arthur Fuller) Date: Fri, 8 Jun 2012 11:20:00 -0400 Subject: [dba-SQLServer] Random autonumber ID In-Reply-To: References: Message-ID: Gustav, IMO this is not the best method, and not even the second or third best method. If for reason you or the client doesn't like AutoNumber, that's cool. I have dealt with such unruly clients in the past (c.f. my missive on long-lasting hardware) Back to the subject: if for some asinine reason, the client doesn't like AutoNumber, then present her with the alternative, GUID, which according to MS's statisticians, is guaranteed to work for the next 70+ years. By which time I shall be dead, and therefore unavailable for post-midnight fixes. Sorry, but Arthur has left the building. Which reminds me of a couple of websites I happened upon this week. "Why can't we just get a Bong?" Marijuana party of Canadia. And the other one I forget. LOL. From jwcolby at colbyconsulting.com Fri Jun 8 10:27:21 2012 From: jwcolby at colbyconsulting.com (jwcolby) Date: Fri, 08 Jun 2012 11:27:21 -0400 Subject: [dba-SQLServer] Random autonumber ID In-Reply-To: References: Message-ID: <4FD219D9.8010603@colbyconsulting.com> The random autonumber may have come from an attempt to do replication, where the be was placed out many different offices and then merged into one place. Access changes any existing sequential autonumbers to random if you use the replication wizard on an Access container. The problem now is that you can't go back to sequential because your PK will eventually hit a random number higher than the current number and it will fail. Sequential isn't very smart about "going around" existing numbers. John W. Colby Colby Consulting Reality is what refuses to go away when you do not believe in it On 6/8/2012 10:44 AM, Gustav Brock wrote: > Hi all > > I'm working on upsizing an Access backend to SQL Server and used Access' wizard for this. > That worked with no errors. > > However, the client used Random Autonumber for IDs in Access and these are converted to integer with an associated trigger to create the random ID for new records: > > USE [PPT] > GO > /****** Object: Trigger [dbo].[T_UserLastDataTable_ITrig] Script Date: 06/08/2012 16:19:49 ******/ > SET ANSI_NULLS ON > GO > SET QUOTED_IDENTIFIER ON > GO > ALTER TRIGGER [dbo].[T_UserLastDataTable_ITrig] ON [dbo].[UserLastDataTable] > FOR INSERT > AS > SET NOCOUNT ON > DECLARE @randc int, @newc int > /* EMULATION CODE FOR AUTONUMBERING */ > /* * EMULATION CODE FOR RANDOM AUTONUMBERING FOR FIELD "ID" */ > SELECT @randc = (SELECT convert(int, rand() * power(2, 30))) > SELECT @newc = (SELECT ID FROM inserted) > > UPDATE UserLastDataTable SET ID = @randc WHERE ID = @newc > > > Is this really the best method? > Any disadvantages? > Would we be better off changing ID in Access to either sequential IDs or even GUID before running the update wizard? > > /gustav > > _______________________________________________ > dba-SQLServer mailing list > dba-SQLServer at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/dba-sqlserver > http://www.databaseadvisors.com > > From jlawrenc1 at shaw.ca Fri Jun 8 11:07:40 2012 From: jlawrenc1 at shaw.ca (Jim Lawrence) Date: Fri, 8 Jun 2012 09:07:40 -0700 Subject: [dba-SQLServer] Random autonumber ID In-Reply-To: References: Message-ID: <66DFA55853944AC2A71A37EA54C68CEF@creativesystemdesigns.com> If data collision is never going to be an issue then random numbers are fine but then it asks the question, "Why". I prefer a controlled sequential numbering system with an appropriate location prefix but another system that can be used is to assemble a serial date+time value. The number is always proceeding, never any data collisions and it have addition uses. I use a similar method in account transactions where easy forensic account be done in the future. Jim -----Original Message----- From: dba-sqlserver-bounces at databaseadvisors.com [mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Gustav Brock Sent: Friday, June 08, 2012 7:44 AM To: dba-sqlserver at databaseadvisors.com Subject: [dba-SQLServer] Random autonumber ID Hi all I'm working on upsizing an Access backend to SQL Server and used Access' wizard for this. That worked with no errors. However, the client used Random Autonumber for IDs in Access and these are converted to integer with an associated trigger to create the random ID for new records: USE [PPT] GO /****** Object: Trigger [dbo].[T_UserLastDataTable_ITrig] Script Date: 06/08/2012 16:19:49 ******/ SET ANSI_NULLS ON GO SET QUOTED_IDENTIFIER ON GO ALTER TRIGGER [dbo].[T_UserLastDataTable_ITrig] ON [dbo].[UserLastDataTable] FOR INSERT AS SET NOCOUNT ON DECLARE @randc int, @newc int /* EMULATION CODE FOR AUTONUMBERING */ /* * EMULATION CODE FOR RANDOM AUTONUMBERING FOR FIELD "ID" */ SELECT @randc = (SELECT convert(int, rand() * power(2, 30))) SELECT @newc = (SELECT ID FROM inserted) UPDATE UserLastDataTable SET ID = @randc WHERE ID = @newc Is this really the best method? Any disadvantages? Would we be better off changing ID in Access to either sequential IDs or even GUID before running the update wizard? /gustav _______________________________________________ dba-SQLServer mailing list dba-SQLServer at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/dba-sqlserver http://www.databaseadvisors.com From marklbreen at gmail.com Mon Jun 11 03:33:14 2012 From: marklbreen at gmail.com (Mark Breen) Date: Mon, 11 Jun 2012 09:33:14 +0100 Subject: [dba-SQLServer] Trigger syntax In-Reply-To: References: Message-ID: Hello Gustav I just copied your code into SSMS, change the two table names and it worked. It created a trigger on a db here locally on my machine. The only thing I had to do was change the Alter to a Create. Would that be your problem? If not, the only other thought that comes to mind is the PPT database the one with the table to hold the trigger. IOW, does the db and table exist? Sorry I could not help more, Mark On 8 June 2012 14:08, Gustav Brock wrote: > Hi all > > I'm new to triggers but I've managed to create this which works as > intended: > > USE [PPT] > GO > /****** Object: Trigger [dbo].[T_VariantsTable_UTrig] Script Date: > 06/08/2012 14:45:17 ******/ > SET ANSI_NULLS ON > GO > SET QUOTED_IDENTIFIER ON > GO > -- ============================================================= > -- Author: Gustav Brock > -- Create date: 2012-06-08 > -- Description: Update field Created to time of update of record > -- ============================================================= > ALTER TRIGGER [dbo].[T_VariantsTable_UTrig] > ON [dbo].[VariantsTable] > FOR UPDATE > AS > BEGIN > -- SET NOCOUNT ON added to prevent extra result sets from > -- interfering with SELECT statements. > SET NOCOUNT ON; > > -- Insert statements for trigger here > DECLARE @id INT > DECLARE @now DATETIME > > -- Retrieve ID of changed record. > SELECT @id = (SELECT ID FROM deleted) > -- Get current time without milliseconds. > SELECT @now = DATEADD(SECOND, DATEDIFF(SECOND, '20000101', GETDATE()), > '20000101') > > UPDATE VariantsTable > SET Changed = @now > WHERE ID = @id > END > > However, when I open this in SMMS, this line has the last part red > underlined: > > ALTER TRIGGER [dbo].[T_VariantsTable_UTrig] > > stating: Invalid object name 'dbo.T_VariantsTable_UTrig' > > Why is that? > I have another trigger created by the Access upsize wizard with similar > code: > > ALTER TRIGGER [dbo].[T_VariantsTable_ITrig] > > and nothing is underlined here. > > /gustav > > _______________________________________________ > dba-SQLServer mailing list > dba-SQLServer at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/dba-sqlserver > http://www.databaseadvisors.com > > From gustav at cactus.dk Mon Jun 11 05:36:36 2012 From: gustav at cactus.dk (Gustav Brock) Date: Mon, 11 Jun 2012 12:36:36 +0200 Subject: [dba-SQLServer] Random autonumber ID Message-ID: Hi Arthur Nope. He (the client) just picked random autonumber for the IDs because he somewhere had read that it had some advantages and - as we all know - the number should be meaningless. So I think I will transfer the IDs as is and then see if I can change the field to straight SQL Server autonumbering. Does anyone know what happens when SQL Server for a new record "meets" an ID that is already taken? /gustav >>> fuller.artful at gmail.com 08-06-12 17:20 >>> Gustav, IMO this is not the best method, and not even the second or third best method. If for reason you or the client doesn't like AutoNumber, that's cool. I have dealt with such unruly clients in the past (c.f. my missive on long-lasting hardware) Back to the subject: if for some asinine reason, the client doesn't like AutoNumber, then present her with the alternative, GUID, which according to MS's statisticians, is guaranteed to work for the next 70+ years. By which time I shall be dead, and therefore unavailable for post-midnight fixes. Sorry, but Arthur has left the building. Which reminds me of a couple of websites I happened upon this week. "Why can't we just get a Bong?" Marijuana party of Canadia. And the other one I forget. LOL. From gustav at cactus.dk Mon Jun 11 05:42:07 2012 From: gustav at cactus.dk (Gustav Brock) Date: Mon, 11 Jun 2012 12:42:07 +0200 Subject: [dba-SQLServer] Random autonumber ID Message-ID: Hi John No, it is not originating from replication. This Access database contains only test data where only the meaningful content have lived outside this before as it was a partial import from production data from a SAP system. /gustav >>> jwcolby at colbyconsulting.com 08-06-12 17:27 >>> The random autonumber may have come from an attempt to do replication, where the be was placed out many different offices and then merged into one place. Access changes any existing sequential autonumbers to random if you use the replication wizard on an Access container. The problem now is that you can't go back to sequential because your PK will eventually hit a random number higher than the current number and it will fail. Sequential isn't very smart about "going around" existing numbers. John W. Colby Colby Consulting Reality is what refuses to go away when you do not believe in it On 6/8/2012 10:44 AM, Gustav Brock wrote: > Hi all > > I'm working on upsizing an Access backend to SQL Server and used Access' wizard for this. > That worked with no errors. > > However, the client used Random Autonumber for IDs in Access and these are converted to integer with an associated trigger to create the random ID for new records: > > USE [PPT] > GO > /****** Object: Trigger [dbo].[T_UserLastDataTable_ITrig] Script Date: 06/08/2012 16:19:49 ******/ > SET ANSI_NULLS ON > GO > SET QUOTED_IDENTIFIER ON > GO > ALTER TRIGGER [dbo].[T_UserLastDataTable_ITrig] ON [dbo].[UserLastDataTable] > FOR INSERT > AS > SET NOCOUNT ON > DECLARE @randc int, @newc int > /* EMULATION CODE FOR AUTONUMBERING */ > /* * EMULATION CODE FOR RANDOM AUTONUMBERING FOR FIELD "ID" */ > SELECT @randc = (SELECT convert(int, rand() * power(2, 30))) > SELECT @newc = (SELECT ID FROM inserted) > > UPDATE UserLastDataTable SET ID = @randc WHERE ID = @newc > > > Is this really the best method? > Any disadvantages? > Would we be better off changing ID in Access to either sequential IDs or even GUID before running the update wizard? > > /gustav From gustav at cactus.dk Mon Jun 11 05:54:53 2012 From: gustav at cactus.dk (Gustav Brock) Date: Mon, 11 Jun 2012 12:54:53 +0200 Subject: [dba-SQLServer] Random autonumber ID Message-ID: Hi Jim Sequential numbering is my preference too. If that isn't enough I prefer the GUID because of its simplicity. /gustav >>> jlawrenc1 at shaw.ca 08-06-12 18:07 >>> If data collision is never going to be an issue then random numbers are fine but then it asks the question, "Why". I prefer a controlled sequential numbering system with an appropriate location prefix but another system that can be used is to assemble a serial date+time value. The number is always proceeding, never any data collisions and it have addition uses. I use a similar method in account transactions where easy forensic account be done in the future. Jim -----Original Message----- From: dba-sqlserver-bounces at databaseadvisors.com [mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Gustav Brock Sent: Friday, June 08, 2012 7:44 AM To: dba-sqlserver at databaseadvisors.com Subject: [dba-SQLServer] Random autonumber ID Hi all I'm working on upsizing an Access backend to SQL Server and used Access' wizard for this. That worked with no errors. However, the client used Random Autonumber for IDs in Access and these are converted to integer with an associated trigger to create the random ID for new records: USE [PPT] GO /****** Object: Trigger [dbo].[T_UserLastDataTable_ITrig] Script Date: 06/08/2012 16:19:49 ******/ SET ANSI_NULLS ON GO SET QUOTED_IDENTIFIER ON GO ALTER TRIGGER [dbo].[T_UserLastDataTable_ITrig] ON [dbo].[UserLastDataTable] FOR INSERT AS SET NOCOUNT ON DECLARE @randc int, @newc int /* EMULATION CODE FOR AUTONUMBERING */ /* * EMULATION CODE FOR RANDOM AUTONUMBERING FOR FIELD "ID" */ SELECT @randc = (SELECT convert(int, rand() * power(2, 30))) SELECT @newc = (SELECT ID FROM inserted) UPDATE UserLastDataTable SET ID = @randc WHERE ID = @newc Is this really the best method? Any disadvantages? Would we be better off changing ID in Access to either sequential IDs or even GUID before running the update wizard? /gustav From gustav at cactus.dk Mon Jun 11 06:10:20 2012 From: gustav at cactus.dk (Gustav Brock) Date: Mon, 11 Jun 2012 13:10:20 +0200 Subject: [dba-SQLServer] Trigger syntax Message-ID: Hi Mark The code below was the code generated by the SQL template which is created when you add a new trigger. As you know, when you run the SQL containing "CREATE ...", the trigger itself containing "ALTER ..." is created. A trigger for Insert already existed. It is named [dbo].[T_VariantsTable_ITrig]. That's why I chose the name [dbo].[T_VariantsTable_UTrig] for my Update trigger. However, this morning - after my workstation had been closed down for the weekend - the issue has vanished. So, for some reason, the new trigger hadn't been saved in full - or what? I really did logout and login again several times and refreshed "everything". But no reboot. Is that really needed? /gustav >>> marklbreen at gmail.com 11-06-12 10:33 >>> Hello Gustav I just copied your code into SSMS, change the two table names and it worked. It created a trigger on a db here locally on my machine. The only thing I had to do was change the Alter to a Create. Would that be your problem? If not, the only other thought that comes to mind is the PPT database the one with the table to hold the trigger. IOW, does the db and table exist? Sorry I could not help more, Mark On 8 June 2012 14:08, Gustav Brock wrote: > Hi all > > I'm new to triggers but I've managed to create this which works as > intended: > > USE [PPT] > GO > /****** Object: Trigger [dbo].[T_VariantsTable_UTrig] Script Date: > 06/08/2012 14:45:17 ******/ > SET ANSI_NULLS ON > GO > SET QUOTED_IDENTIFIER ON > GO > -- ============================================================= > -- Author: Gustav Brock > -- Create date: 2012-06-08 > -- Description: Update field Created to time of update of record > -- ============================================================= > ALTER TRIGGER [dbo].[T_VariantsTable_UTrig] > ON [dbo].[VariantsTable] > FOR UPDATE > AS > BEGIN > -- SET NOCOUNT ON added to prevent extra result sets from > -- interfering with SELECT statements. > SET NOCOUNT ON; > > -- Insert statements for trigger here > DECLARE @id INT > DECLARE @now DATETIME > > -- Retrieve ID of changed record. > SELECT @id = (SELECT ID FROM deleted) > -- Get current time without milliseconds. > SELECT @now = DATEADD(SECOND, DATEDIFF(SECOND, '20000101', GETDATE()), > '20000101') > > UPDATE VariantsTable > SET Changed = @now > WHERE ID = @id > END > > However, when I open this in SMMS, this line has the last part red > underlined: > > ALTER TRIGGER [dbo].[T_VariantsTable_UTrig] > > stating: Invalid object name 'dbo.T_VariantsTable_UTrig' > > Why is that? > I have another trigger created by the Access upsize wizard with similar > code: > > ALTER TRIGGER [dbo].[T_VariantsTable_ITrig] > > and nothing is underlined here. > > /gustav From accessd at shaw.ca Mon Jun 11 12:12:12 2012 From: accessd at shaw.ca (Jim Lawrence) Date: Mon, 11 Jun 2012 10:12:12 -0700 Subject: [dba-SQLServer] Random autonumber ID In-Reply-To: References: Message-ID: <0B2AFAF61FBE43D3875149E3E1B0E17A@creativesystemdesigns.com> Most of my systems are set up with transaction keys on every record and nothing is ever deleted, just no longer displayed. Slowly, via a moving window all the records tagged as deleted as moved to posted tables. I know this process is very old school but it has saved many companies when a bit of forensic analysis of their data is required. The client is always right, even when they are wrong but as the IT guy, it is dependant on you to give them what they and want and what they need. Jim -----Original Message----- From: dba-sqlserver-bounces at databaseadvisors.com [mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Gustav Brock Sent: Monday, June 11, 2012 3:55 AM To: dba-sqlserver at databaseadvisors.com Subject: Re: [dba-SQLServer] Random autonumber ID Hi Jim Sequential numbering is my preference too. If that isn't enough I prefer the GUID because of its simplicity. /gustav >>> jlawrenc1 at shaw.ca 08-06-12 18:07 >>> If data collision is never going to be an issue then random numbers are fine but then it asks the question, "Why". I prefer a controlled sequential numbering system with an appropriate location prefix but another system that can be used is to assemble a serial date+time value. The number is always proceeding, never any data collisions and it have addition uses. I use a similar method in account transactions where easy forensic account be done in the future. Jim -----Original Message----- From: dba-sqlserver-bounces at databaseadvisors.com [mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Gustav Brock Sent: Friday, June 08, 2012 7:44 AM To: dba-sqlserver at databaseadvisors.com Subject: [dba-SQLServer] Random autonumber ID Hi all I'm working on upsizing an Access backend to SQL Server and used Access' wizard for this. That worked with no errors. However, the client used Random Autonumber for IDs in Access and these are converted to integer with an associated trigger to create the random ID for new records: USE [PPT] GO /****** Object: Trigger [dbo].[T_UserLastDataTable_ITrig] Script Date: 06/08/2012 16:19:49 ******/ SET ANSI_NULLS ON GO SET QUOTED_IDENTIFIER ON GO ALTER TRIGGER [dbo].[T_UserLastDataTable_ITrig] ON [dbo].[UserLastDataTable] FOR INSERT AS SET NOCOUNT ON DECLARE @randc int, @newc int /* EMULATION CODE FOR AUTONUMBERING */ /* * EMULATION CODE FOR RANDOM AUTONUMBERING FOR FIELD "ID" */ SELECT @randc = (SELECT convert(int, rand() * power(2, 30))) SELECT @newc = (SELECT ID FROM inserted) UPDATE UserLastDataTable SET ID = @randc WHERE ID = @newc Is this really the best method? Any disadvantages? Would we be better off changing ID in Access to either sequential IDs or even GUID before running the update wizard? /gustav _______________________________________________ dba-SQLServer mailing list dba-SQLServer at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/dba-sqlserver http://www.databaseadvisors.com From accessd at shaw.ca Mon Jun 11 12:14:01 2012 From: accessd at shaw.ca (Jim Lawrence) Date: Mon, 11 Jun 2012 10:14:01 -0700 Subject: [dba-SQLServer] Trigger syntax In-Reply-To: References: Message-ID: <0C5ADF0495B748368FA9329CAFFEC8FF@creativesystemdesigns.com> Hi Gustav: Have set up all the permissions right? Jim -----Original Message----- From: dba-sqlserver-bounces at databaseadvisors.com [mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Gustav Brock Sent: Monday, June 11, 2012 4:10 AM To: dba-sqlserver at databaseadvisors.com Subject: Re: [dba-SQLServer] Trigger syntax Hi Mark The code below was the code generated by the SQL template which is created when you add a new trigger. As you know, when you run the SQL containing "CREATE ...", the trigger itself containing "ALTER ..." is created. A trigger for Insert already existed. It is named [dbo].[T_VariantsTable_ITrig]. That's why I chose the name [dbo].[T_VariantsTable_UTrig] for my Update trigger. However, this morning - after my workstation had been closed down for the weekend - the issue has vanished. So, for some reason, the new trigger hadn't been saved in full - or what? I really did logout and login again several times and refreshed "everything". But no reboot. Is that really needed? /gustav >>> marklbreen at gmail.com 11-06-12 10:33 >>> Hello Gustav I just copied your code into SSMS, change the two table names and it worked. It created a trigger on a db here locally on my machine. The only thing I had to do was change the Alter to a Create. Would that be your problem? If not, the only other thought that comes to mind is the PPT database the one with the table to hold the trigger. IOW, does the db and table exist? Sorry I could not help more, Mark On 8 June 2012 14:08, Gustav Brock wrote: > Hi all > > I'm new to triggers but I've managed to create this which works as > intended: > > USE [PPT] > GO > /****** Object: Trigger [dbo].[T_VariantsTable_UTrig] Script Date: > 06/08/2012 14:45:17 ******/ > SET ANSI_NULLS ON > GO > SET QUOTED_IDENTIFIER ON > GO > -- ============================================================= > -- Author: Gustav Brock > -- Create date: 2012-06-08 > -- Description: Update field Created to time of update of record > -- ============================================================= > ALTER TRIGGER [dbo].[T_VariantsTable_UTrig] > ON [dbo].[VariantsTable] > FOR UPDATE > AS > BEGIN > -- SET NOCOUNT ON added to prevent extra result sets from > -- interfering with SELECT statements. > SET NOCOUNT ON; > > -- Insert statements for trigger here > DECLARE @id INT > DECLARE @now DATETIME > > -- Retrieve ID of changed record. > SELECT @id = (SELECT ID FROM deleted) > -- Get current time without milliseconds. > SELECT @now = DATEADD(SECOND, DATEDIFF(SECOND, '20000101', GETDATE()), > '20000101') > > UPDATE VariantsTable > SET Changed = @now > WHERE ID = @id > END > > However, when I open this in SMMS, this line has the last part red > underlined: > > ALTER TRIGGER [dbo].[T_VariantsTable_UTrig] > > stating: Invalid object name 'dbo.T_VariantsTable_UTrig' > > Why is that? > I have another trigger created by the Access upsize wizard with similar > code: > > ALTER TRIGGER [dbo].[T_VariantsTable_ITrig] > > and nothing is underlined here. > > /gustav _______________________________________________ dba-SQLServer mailing list dba-SQLServer at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/dba-sqlserver http://www.databaseadvisors.com From marklbreen at gmail.com Tue Jun 12 03:23:03 2012 From: marklbreen at gmail.com (Mark Breen) Date: Tue, 12 Jun 2012 09:23:03 +0100 Subject: [dba-SQLServer] Random autonumber ID In-Reply-To: References: Message-ID: Hello Gustav, I think that SQL Server will automatically pick up at the largest number currently in the table and work away happily. If not, you can easily set the starting number for the new range using DBCC CHECKIDENT In fact, if the last random number was 547845714 you could make the next Identity Insert start at 6000000000 Mark On 11 June 2012 11:36, Gustav Brock wrote: > Hi Arthur > > Nope. He (the client) just picked random autonumber for the IDs because he > somewhere had read that it had some advantages and - as we all know - the > number should be meaningless. > > So I think I will transfer the IDs as is and then see if I can change the > field to straight SQL Server autonumbering. > Does anyone know what happens when SQL Server for a new record "meets" an > ID that is already taken? > > /gustav > > > >>> fuller.artful at gmail.com 08-06-12 17:20 >>> > Gustav, > > IMO this is not the best method, and not even the second or third best > method. If for reason you or the client doesn't like AutoNumber, that's > cool. I have dealt with such unruly clients in the past (c.f. my missive on > long-lasting hardware) Back to the subject: if for some asinine reason, the > client doesn't like AutoNumber, then present her with the alternative, > GUID, which according to MS's statisticians, is guaranteed to work for the > next 70+ years. By which time I shall be dead, and therefore unavailable > for post-midnight fixes. Sorry, but Arthur has left the building. > > Which reminds me of a couple of websites I happened upon this week. > > "Why can't we just get a Bong?" Marijuana party of Canadia. And the other > one I forget. LOL. > > > _______________________________________________ > dba-SQLServer mailing list > dba-SQLServer at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/dba-sqlserver > http://www.databaseadvisors.com > > From marklbreen at gmail.com Tue Jun 12 03:24:57 2012 From: marklbreen at gmail.com (Mark Breen) Date: Tue, 12 Jun 2012 09:24:57 +0100 Subject: [dba-SQLServer] Trigger syntax In-Reply-To: References: Message-ID: Hello Gustav I have not used triggers extensively, but I am 100% sure they do not require a reboot to work :) Guess it is just one of those things. Mark On 11 June 2012 12:10, Gustav Brock wrote: > Hi Mark > > The code below was the code generated by the SQL template which is created > when you add a new trigger. > As you know, when you run the SQL containing "CREATE ...", the trigger > itself containing "ALTER ..." is created. > A trigger for Insert already existed. It is named > [dbo].[T_VariantsTable_ITrig]. > That's why I chose the name [dbo].[T_VariantsTable_UTrig] for my Update > trigger. > > However, this morning - after my workstation had been closed down for the > weekend - the issue has vanished. So, for some reason, the new trigger > hadn't been saved in full - or what? I really did logout and login again > several times and refreshed "everything". But no reboot. Is that really > needed? > > /gustav > > > >>> marklbreen at gmail.com 11-06-12 10:33 >>> > Hello Gustav > > I just copied your code into SSMS, change the two table names and it > worked. It created a trigger on a db here locally on my machine. > > The only thing I had to do was change the Alter to a Create. Would that be > your problem? > > If not, the only other thought that comes to mind is the PPT database the > one with the table to hold the trigger. IOW, does the db and table exist? > > Sorry I could not help more, > > Mark > > > On 8 June 2012 14:08, Gustav Brock wrote: > > > Hi all > > > > I'm new to triggers but I've managed to create this which works as > > intended: > > > > USE [PPT] > > GO > > /****** Object: Trigger [dbo].[T_VariantsTable_UTrig] Script Date: > > 06/08/2012 14:45:17 ******/ > > SET ANSI_NULLS ON > > GO > > SET QUOTED_IDENTIFIER ON > > GO > > -- ============================================================= > > -- Author: Gustav Brock > > -- Create date: 2012-06-08 > > -- Description: Update field Created to time of update of record > > -- ============================================================= > > ALTER TRIGGER [dbo].[T_VariantsTable_UTrig] > > ON [dbo].[VariantsTable] > > FOR UPDATE > > AS > > BEGIN > > -- SET NOCOUNT ON added to prevent extra result sets from > > -- interfering with SELECT statements. > > SET NOCOUNT ON; > > > > -- Insert statements for trigger here > > DECLARE @id INT > > DECLARE @now DATETIME > > > > -- Retrieve ID of changed record. > > SELECT @id = (SELECT ID FROM deleted) > > -- Get current time without milliseconds. > > SELECT @now = DATEADD(SECOND, DATEDIFF(SECOND, '20000101', GETDATE()), > > '20000101') > > > > UPDATE VariantsTable > > SET Changed = @now > > WHERE ID = @id > > END > > > > However, when I open this in SMMS, this line has the last part red > > underlined: > > > > ALTER TRIGGER [dbo].[T_VariantsTable_UTrig] > > > > stating: Invalid object name 'dbo.T_VariantsTable_UTrig' > > > > Why is that? > > I have another trigger created by the Access upsize wizard with similar > > code: > > > > ALTER TRIGGER [dbo].[T_VariantsTable_ITrig] > > > > and nothing is underlined here. > > > > /gustav > > _______________________________________________ > dba-SQLServer mailing list > dba-SQLServer at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/dba-sqlserver > http://www.databaseadvisors.com > > From gustav at cactus.dk Tue Jun 12 03:39:58 2012 From: gustav at cactus.dk (Gustav Brock) Date: Tue, 12 Jun 2012 10:39:58 +0200 Subject: [dba-SQLServer] Trigger syntax Message-ID: Hi Jim Yes, nothing fancy. And besides, the trigger works fine. I guess somehow the new trigger, though saved and working, was not recognised by its name as a member of the collection by the intellisense until a reboot had happened. /gustav >>> accessd at shaw.ca 11-06-12 19:14 >>> Hi Gustav: Have set up all the permissions right? Jim -----Original Message----- From: dba-sqlserver-bounces at databaseadvisors.com [mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Gustav Brock Sent: Monday, June 11, 2012 4:10 AM To: dba-sqlserver at databaseadvisors.com Subject: Re: [dba-SQLServer] Trigger syntax Hi Mark The code below was the code generated by the SQL template which is created when you add a new trigger. As you know, when you run the SQL containing "CREATE ...", the trigger itself containing "ALTER ..." is created. A trigger for Insert already existed. It is named [dbo].[T_VariantsTable_ITrig]. That's why I chose the name [dbo].[T_VariantsTable_UTrig] for my Update trigger. However, this morning - after my workstation had been closed down for the weekend - the issue has vanished. So, for some reason, the new trigger hadn't been saved in full - or what? I really did logout and login again several times and refreshed "everything". But no reboot. Is that really needed? /gustav >>> marklbreen at gmail.com 11-06-12 10:33 >>> Hello Gustav I just copied your code into SSMS, change the two table names and it worked. It created a trigger on a db here locally on my machine. The only thing I had to do was change the Alter to a Create. Would that be your problem? If not, the only other thought that comes to mind is the PPT database the one with the table to hold the trigger. IOW, does the db and table exist? Sorry I could not help more, Mark On 8 June 2012 14:08, Gustav Brock wrote: > Hi all > > I'm new to triggers but I've managed to create this which works as > intended: > > USE [PPT] > GO > /****** Object: Trigger [dbo].[T_VariantsTable_UTrig] Script Date: > 06/08/2012 14:45:17 ******/ > SET ANSI_NULLS ON > GO > SET QUOTED_IDENTIFIER ON > GO > -- ============================================================= > -- Author: Gustav Brock > -- Create date: 2012-06-08 > -- Description: Update field Created to time of update of record > -- ============================================================= > ALTER TRIGGER [dbo].[T_VariantsTable_UTrig] > ON [dbo].[VariantsTable] > FOR UPDATE > AS > BEGIN > -- SET NOCOUNT ON added to prevent extra result sets from > -- interfering with SELECT statements. > SET NOCOUNT ON; > > -- Insert statements for trigger here > DECLARE @id INT > DECLARE @now DATETIME > > -- Retrieve ID of changed record. > SELECT @id = (SELECT ID FROM deleted) > -- Get current time without milliseconds. > SELECT @now = DATEADD(SECOND, DATEDIFF(SECOND, '20000101', GETDATE()), > '20000101') > > UPDATE VariantsTable > SET Changed = @now > WHERE ID = @id > END > > However, when I open this in SMMS, this line has the last part red > underlined: > > ALTER TRIGGER [dbo].[T_VariantsTable_UTrig] > > stating: Invalid object name 'dbo.T_VariantsTable_UTrig' > > Why is that? > I have another trigger created by the Access upsize wizard with similar > code: > > ALTER TRIGGER [dbo].[T_VariantsTable_ITrig] > > and nothing is underlined here. > > /gustav From gustav at cactus.dk Tue Jun 12 04:27:49 2012 From: gustav at cactus.dk (Gustav Brock) Date: Tue, 12 Jun 2012 11:27:49 +0200 Subject: [dba-SQLServer] Random autonumber ID Message-ID: Hi Mark Thanks, I didn't know that. By the way, I located this page: http://e-university.wisdomjobs.com/ms-access/chapter-1413-203/upsizing-access-to-sql-server.html which has a very good explanation of the pitfalls in the paragraph: "Replicated Databases and Random Autonumbers") This tells me that I once again should try to persuade the client to bite the bullet and revert to sequential IDs. /gustav >>> marklbreen at gmail.com 12-06-12 10:23 >>> Hello Gustav, I think that SQL Server will automatically pick up at the largest number currently in the table and work away happily. If not, you can easily set the starting number for the new range using DBCC CHECKIDENT In fact, if the last random number was 547845714 you could make the next Identity Insert start at 6000000000 Mark On 11 June 2012 11:36, Gustav Brock wrote: > Hi Arthur > > Nope. He (the client) just picked random autonumber for the IDs because he > somewhere had read that it had some advantages and - as we all know - the > number should be meaningless. > > So I think I will transfer the IDs as is and then see if I can change the > field to straight SQL Server autonumbering. > Does anyone know what happens when SQL Server for a new record "meets" an > ID that is already taken? > > /gustav > > > >>> fuller.artful at gmail.com 08-06-12 17:20 >>> > Gustav, > > IMO this is not the best method, and not even the second or third best > method. If for reason you or the client doesn't like AutoNumber, that's > cool. I have dealt with such unruly clients in the past (c.f. my missive on > long-lasting hardware) Back to the subject: if for some asinine reason, the > client doesn't like AutoNumber, then present her with the alternative, > GUID, which according to MS's statisticians, is guaranteed to work for the > next 70+ years. By which time I shall be dead, and therefore unavailable > for post-midnight fixes. Sorry, but Arthur has left the building. > > Which reminds me of a couple of websites I happened upon this week. > > "Why can't we just get a Bong?" Marijuana party of Canadia. And the other > one I forget. LOL. From jwcolby at colbyconsulting.com Tue Jun 12 09:18:53 2012 From: jwcolby at colbyconsulting.com (jwcolby) Date: Tue, 12 Jun 2012 10:18:53 -0400 Subject: [dba-SQLServer] Random autonumber ID In-Reply-To: References: Message-ID: <4FD74FCD.2090304@colbyconsulting.com> Mark, The problem with that theory is that the PKs are scattered "randomly" through the numeric range. So there is no "largest number" or that number could be waaaayyyy up in the numeric range, in fact it could be one below the "rollover" value. You understand what I am saying? John W. Colby Colby Consulting Reality is what refuses to go away when you do not believe in it On 6/12/2012 4:23 AM, Mark Breen wrote: > Hello Gustav, > > I think that SQL Server will automatically pick up at the largest number > currently in the table and work away happily. If not, you can easily set > the starting number for the new range using DBCC CHECKIDENT > > In fact, if the last random number was 547845714 you could make the next > Identity Insert start at 6000000000 > > Mark > > > > On 11 June 2012 11:36, Gustav Brock wrote: > >> Hi Arthur >> >> Nope. He (the client) just picked random autonumber for the IDs because he >> somewhere had read that it had some advantages and - as we all know - the >> number should be meaningless. >> >> So I think I will transfer the IDs as is and then see if I can change the >> field to straight SQL Server autonumbering. >> Does anyone know what happens when SQL Server for a new record "meets" an >> ID that is already taken? >> >> /gustav >> >> >>>>> fuller.artful at gmail.com 08-06-12 17:20>>> >> Gustav, >> >> IMO this is not the best method, and not even the second or third best >> method. If for reason you or the client doesn't like AutoNumber, that's >> cool. I have dealt with such unruly clients in the past (c.f. my missive on >> long-lasting hardware) Back to the subject: if for some asinine reason, the >> client doesn't like AutoNumber, then present her with the alternative, >> GUID, which according to MS's statisticians, is guaranteed to work for the >> next 70+ years. By which time I shall be dead, and therefore unavailable >> for post-midnight fixes. Sorry, but Arthur has left the building. >> >> Which reminds me of a couple of websites I happened upon this week. >> >> "Why can't we just get a Bong?" Marijuana party of Canadia. And the other >> one I forget. LOL. >> >> >> _______________________________________________ >> dba-SQLServer mailing list >> dba-SQLServer at databaseadvisors.com >> http://databaseadvisors.com/mailman/listinfo/dba-sqlserver >> http://www.databaseadvisors.com >> >> > _______________________________________________ > dba-SQLServer mailing list > dba-SQLServer at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/dba-sqlserver > http://www.databaseadvisors.com > > From jwcolby at colbyconsulting.com Tue Jun 12 09:20:43 2012 From: jwcolby at colbyconsulting.com (jwcolby) Date: Tue, 12 Jun 2012 10:20:43 -0400 Subject: [dba-SQLServer] Random autonumber ID In-Reply-To: References: Message-ID: <4FD7503B.7070208@colbyconsulting.com> The problem is that in order to revert you have to manually rebuild the autonumber PKs by moving the data into a new table with a new autonumber, plus the old "random" autonumber. You then have to update all child tables with then new PK values. This is darned ugly and error prone. John W. Colby Colby Consulting Reality is what refuses to go away when you do not believe in it On 6/12/2012 5:27 AM, Gustav Brock wrote: > Hi Mark > > Thanks, I didn't know that. > > By the way, I located this page: > http://e-university.wisdomjobs.com/ms-access/chapter-1413-203/upsizing-access-to-sql-server.html > > which has a very good explanation of the pitfalls in the paragraph: > "Replicated Databases and Random Autonumbers") > > This tells me that I once again should try to persuade the client to bite the bullet and revert to sequential IDs. > > /gustav > > >>>> marklbreen at gmail.com 12-06-12 10:23>>> > Hello Gustav, > > I think that SQL Server will automatically pick up at the largest number > currently in the table and work away happily. If not, you can easily set > the starting number for the new range using DBCC CHECKIDENT > > In fact, if the last random number was 547845714 you could make the next > Identity Insert start at 6000000000 > > Mark > > > > On 11 June 2012 11:36, Gustav Brock wrote: > >> Hi Arthur >> >> Nope. He (the client) just picked random autonumber for the IDs because he >> somewhere had read that it had some advantages and - as we all know - the >> number should be meaningless. >> >> So I think I will transfer the IDs as is and then see if I can change the >> field to straight SQL Server autonumbering. >> Does anyone know what happens when SQL Server for a new record "meets" an >> ID that is already taken? >> >> /gustav >> >> >>>>> fuller.artful at gmail.com 08-06-12 17:20>>> >> Gustav, >> >> IMO this is not the best method, and not even the second or third best >> method. If for reason you or the client doesn't like AutoNumber, that's >> cool. I have dealt with such unruly clients in the past (c.f. my missive on >> long-lasting hardware) Back to the subject: if for some asinine reason, the >> client doesn't like AutoNumber, then present her with the alternative, >> GUID, which according to MS's statisticians, is guaranteed to work for the >> next 70+ years. By which time I shall be dead, and therefore unavailable >> for post-midnight fixes. Sorry, but Arthur has left the building. >> >> Which reminds me of a couple of websites I happened upon this week. >> >> "Why can't we just get a Bong?" Marijuana party of Canadia. And the other >> one I forget. LOL. > > _______________________________________________ > dba-SQLServer mailing list > dba-SQLServer at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/dba-sqlserver > http://www.databaseadvisors.com > > From gustav at cactus.dk Tue Jun 12 10:06:34 2012 From: gustav at cactus.dk (Gustav Brock) Date: Tue, 12 Jun 2012 17:06:34 +0200 Subject: [dba-SQLServer] Random autonumber ID Message-ID: Hi John This, trivial and cumbersome. However, the client has accepted to move to sequential numbers. The reason for the random numbers were, that the column this way looked "different" when perusing the table. Not a very heavy argument, he admitted. /gustav >>> jwcolby at colbyconsulting.com 12-06-12 16:20 >>> The problem is that in order to revert you have to manually rebuild the autonumber PKs by moving the data into a new table with a new autonumber, plus the old "random" autonumber. You then have to update all child tables with then new PK values. This is darned ugly and error prone. John W. Colby Colby Consulting Reality is what refuses to go away when you do not believe in it On 6/12/2012 5:27 AM, Gustav Brock wrote: > Hi Mark > > Thanks, I didn't know that. > > By the way, I located this page: > http://e-university.wisdomjobs.com/ms-access/chapter-1413-203/upsizing-access-to-sql-server.html > > which has a very good explanation of the pitfalls in the paragraph: > "Replicated Databases and Random Autonumbers") > > This tells me that I once again should try to persuade the client to bite the bullet and revert to sequential IDs. > > /gustav > > >>>> marklbreen at gmail.com 12-06-12 10:23>>> > Hello Gustav, > > I think that SQL Server will automatically pick up at the largest number > currently in the table and work away happily. If not, you can easily set > the starting number for the new range using DBCC CHECKIDENT > > In fact, if the last random number was 547845714 you could make the next > Identity Insert start at 6000000000 > > Mark From stuart at lexacorp.com.pg Tue Jun 12 17:43:11 2012 From: stuart at lexacorp.com.pg (Stuart McLachlan) Date: Wed, 13 Jun 2012 08:43:11 +1000 Subject: [dba-SQLServer] Random autonumber ID In-Reply-To: References: Message-ID: <4FD7C5FF.219.9D43D32@stuart.lexacorp.com.pg> If the client wants the random numbers to look "different", seed the table with a large value such as 9,000,000,000,000. -- Stuart On 12 Jun 2012 at 17:06, Gustav Brock wrote: > Hi John > > This, trivial and cumbersome. > > However, the client has accepted to move to sequential numbers. The reason for the random numbers were, that the column this way looked "different" when perusing the table. Not a very heavy argument, he admitted. > > /gustav > > > >>> jwcolby at colbyconsulting.com 12-06-12 16:20 >>> > The problem is that in order to revert you have to manually rebuild the autonumber PKs by moving the > data into a new table with a new autonumber, plus the old "random" autonumber. You then have to > update all child tables with then new PK values. This is darned ugly and error prone. > > John W. Colby > Colby Consulting > > Reality is what refuses to go away > when you do not believe in it > > On 6/12/2012 5:27 AM, Gustav Brock wrote: > > Hi Mark > > > > Thanks, I didn't know that. > > > > By the way, I located this page: > > http://e-university.wisdomjobs.com/ms-access/chapter-1413-203/upsizing-access-to-sql-server.html > > > > which has a very good explanation of the pitfalls in the paragraph: > > "Replicated Databases and Random Autonumbers") > > > > This tells me that I once again should try to persuade the client to bite the bullet and revert to sequential IDs. > > > > /gustav > > > > > >>>> marklbreen at gmail.com 12-06-12 10:23>>> > > Hello Gustav, > > > > I think that SQL Server will automatically pick up at the largest number > > currently in the table and work away happily. If not, you can easily set > > the starting number for the new range using DBCC CHECKIDENT > > > > In fact, if the last random number was 547845714 you could make the next > > Identity Insert start at 6000000000 > > > > Mark > > _______________________________________________ > dba-SQLServer mailing list > dba-SQLServer at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/dba-sqlserver > http://www.databaseadvisors.com > > -- Stuart McLachlan Ph: +675 340 4392 Mob: +675 7100 2028 Web: http://www.lexacorp.com.pg From marklbreen at gmail.com Thu Jun 14 04:30:28 2012 From: marklbreen at gmail.com (Mark Breen) Date: Thu, 14 Jun 2012 10:30:28 +0100 Subject: [dba-SQLServer] Trigger syntax In-Reply-To: References: Message-ID: Hello Gustav, Oh yes, the intellisense can cause a lot of hassle chasing a syntax error that does not exist. Do you use SQL Prompt by Redgate? Mark On 12 June 2012 09:39, Gustav Brock wrote: > Hi Jim > > Yes, nothing fancy. And besides, the trigger works fine. > > I guess somehow the new trigger, though saved and working, was not > recognised by its name as a member of the collection by the intellisense > until a reboot had happened. > > /gustav > > > >>> accessd at shaw.ca 11-06-12 19:14 >>> > Hi Gustav: > > Have set up all the permissions right? > > Jim > > -----Original Message----- > From: dba-sqlserver-bounces at databaseadvisors.com > [mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Gustav > Brock > Sent: Monday, June 11, 2012 4:10 AM > To: dba-sqlserver at databaseadvisors.com > Subject: Re: [dba-SQLServer] Trigger syntax > > Hi Mark > > The code below was the code generated by the SQL template which is created > when you add a new trigger. > As you know, when you run the SQL containing "CREATE ...", the trigger > itself containing "ALTER ..." is created. > A trigger for Insert already existed. It is named > [dbo].[T_VariantsTable_ITrig]. > That's why I chose the name [dbo].[T_VariantsTable_UTrig] for my Update > trigger. > > However, this morning - after my workstation had been closed down for the > weekend - the issue has vanished. So, for some reason, the new trigger > hadn't been saved in full - or what? I really did logout and login again > several times and refreshed "everything". But no reboot. Is that really > needed? > > /gustav > > > >>> marklbreen at gmail.com 11-06-12 10:33 >>> > Hello Gustav > > I just copied your code into SSMS, change the two table names and it > worked. It created a trigger on a db here locally on my machine. > > The only thing I had to do was change the Alter to a Create. Would that be > your problem? > > If not, the only other thought that comes to mind is the PPT database the > one with the table to hold the trigger. IOW, does the db and table exist? > > Sorry I could not help more, > > Mark > > > On 8 June 2012 14:08, Gustav Brock wrote: > > > Hi all > > > > I'm new to triggers but I've managed to create this which works as > > intended: > > > > USE [PPT] > > GO > > /****** Object: Trigger [dbo].[T_VariantsTable_UTrig] Script Date: > > 06/08/2012 14:45:17 ******/ > > SET ANSI_NULLS ON > > GO > > SET QUOTED_IDENTIFIER ON > > GO > > -- ============================================================= > > -- Author: Gustav Brock > > -- Create date: 2012-06-08 > > -- Description: Update field Created to time of update of record > > -- ============================================================= > > ALTER TRIGGER [dbo].[T_VariantsTable_UTrig] > > ON [dbo].[VariantsTable] > > FOR UPDATE > > AS > > BEGIN > > -- SET NOCOUNT ON added to prevent extra result sets from > > -- interfering with SELECT statements. > > SET NOCOUNT ON; > > > > -- Insert statements for trigger here > > DECLARE @id INT > > DECLARE @now DATETIME > > > > -- Retrieve ID of changed record. > > SELECT @id = (SELECT ID FROM deleted) > > -- Get current time without milliseconds. > > SELECT @now = DATEADD(SECOND, DATEDIFF(SECOND, '20000101', GETDATE()), > > '20000101') > > > > UPDATE VariantsTable > > SET Changed = @now > > WHERE ID = @id > > END > > > > However, when I open this in SMMS, this line has the last part red > > underlined: > > > > ALTER TRIGGER [dbo].[T_VariantsTable_UTrig] > > > > stating: Invalid object name 'dbo.T_VariantsTable_UTrig' > > > > Why is that? > > I have another trigger created by the Access upsize wizard with similar > > code: > > > > ALTER TRIGGER [dbo].[T_VariantsTable_ITrig] > > > > and nothing is underlined here. > > > > /gustav > > > _______________________________________________ > dba-SQLServer mailing list > dba-SQLServer at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/dba-sqlserver > http://www.databaseadvisors.com > > From marklbreen at gmail.com Thu Jun 14 04:33:08 2012 From: marklbreen at gmail.com (Mark Breen) Date: Thu, 14 Jun 2012 10:33:08 +0100 Subject: [dba-SQLServer] Random autonumber ID In-Reply-To: <4FD74FCD.2090304@colbyconsulting.com> References: <4FD74FCD.2090304@colbyconsulting.com> Message-ID: Hello John, good point about the roll over value, Mark On 12 June 2012 15:18, jwcolby wrote: > Mark, > > The problem with that theory is that the PKs are scattered "randomly" > through the numeric range. So there is no "largest number" or that number > could be waaaayyyy up in the numeric range, in fact it could be one below > the "rollover" value. > > You understand what I am saying? > > > John W. Colby > Colby Consulting > > Reality is what refuses to go away > when you do not believe in it > > On 6/12/2012 4:23 AM, Mark Breen wrote: > >> Hello Gustav, >> >> I think that SQL Server will automatically pick up at the largest number >> currently in the table and work away happily. If not, you can easily set >> the starting number for the new range using DBCC CHECKIDENT >> >> In fact, if the last random number was 547845714 you could make the next >> Identity Insert start at 6000000000 >> >> Mark >> >> >> >> On 11 June 2012 11:36, Gustav Brock wrote: >> >> Hi Arthur >>> >>> Nope. He (the client) just picked random autonumber for the IDs because >>> he >>> somewhere had read that it had some advantages and - as we all know - the >>> number should be meaningless. >>> >>> So I think I will transfer the IDs as is and then see if I can change the >>> field to straight SQL Server autonumbering. >>> Does anyone know what happens when SQL Server for a new record "meets" an >>> ID that is already taken? >>> >>> /gustav >>> >>> >>> fuller.artful at gmail.com 08-06-12 17:20>>> >>>>>> >>>>> Gustav, >>> >>> IMO this is not the best method, and not even the second or third best >>> method. If for reason you or the client doesn't like AutoNumber, that's >>> cool. I have dealt with such unruly clients in the past (c.f. my missive >>> on >>> long-lasting hardware) Back to the subject: if for some asinine reason, >>> the >>> client doesn't like AutoNumber, then present her with the alternative, >>> GUID, which according to MS's statisticians, is guaranteed to work for >>> the >>> next 70+ years. By which time I shall be dead, and therefore unavailable >>> for post-midnight fixes. Sorry, but Arthur has left the building. >>> >>> Which reminds me of a couple of websites I happened upon this week. >>> >>> "Why can't we just get a Bong?" Marijuana party of Canadia. And the other >>> one I forget. LOL. >>> >>> >>> ______________________________**_________________ >>> dba-SQLServer mailing list >>> dba-SQLServer@**databaseadvisors.com >>> http://databaseadvisors.com/**mailman/listinfo/dba-sqlserver >>> http://www.databaseadvisors.**com >>> >>> >>> ______________________________**_________________ >> dba-SQLServer mailing list >> dba-SQLServer@**databaseadvisors.com >> http://databaseadvisors.com/**mailman/listinfo/dba-sqlserver >> http://www.databaseadvisors.**com >> >> >> > ______________________________**_________________ > dba-SQLServer mailing list > dba-SQLServer@**databaseadvisors.com > http://databaseadvisors.com/**mailman/listinfo/dba-sqlserver > http://www.databaseadvisors.**com > > From gustav at cactus.dk Thu Jun 14 05:17:06 2012 From: gustav at cactus.dk (Gustav Brock) Date: Thu, 14 Jun 2012 12:17:06 +0200 Subject: [dba-SQLServer] Trigger syntax Message-ID: Hi Mark No, I use SSMS. /gustav >>> marklbreen at gmail.com 14-06-12 11:30 >>> Hello Gustav, Oh yes, the intellisense can cause a lot of hassle chasing a syntax error that does not exist. Do you use SQL Prompt by Redgate? Mark On 12 June 2012 09:39, Gustav Brock wrote: > Hi Jim > > Yes, nothing fancy. And besides, the trigger works fine. > > I guess somehow the new trigger, though saved and working, was not > recognised by its name as a member of the collection by the intellisense > until a reboot had happened. > > /gustav > > > >>> accessd at shaw.ca 11-06-12 19:14 >>> > Hi Gustav: > > Have set up all the permissions right? > > Jim > > -----Original Message----- > From: dba-sqlserver-bounces at databaseadvisors.com > [mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Gustav > Brock > Sent: Monday, June 11, 2012 4:10 AM > To: dba-sqlserver at databaseadvisors.com > Subject: Re: [dba-SQLServer] Trigger syntax > > Hi Mark > > The code below was the code generated by the SQL template which is created > when you add a new trigger. > As you know, when you run the SQL containing "CREATE ...", the trigger > itself containing "ALTER ..." is created. > A trigger for Insert already existed. It is named > [dbo].[T_VariantsTable_ITrig]. > That's why I chose the name [dbo].[T_VariantsTable_UTrig] for my Update > trigger. > > However, this morning - after my workstation had been closed down for the > weekend - the issue has vanished. So, for some reason, the new trigger > hadn't been saved in full - or what? I really did logout and login again > several times and refreshed "everything". But no reboot. Is that really > needed? > > /gustav > > > >>> marklbreen at gmail.com 11-06-12 10:33 >>> > Hello Gustav > > I just copied your code into SSMS, change the two table names and it > worked. It created a trigger on a db here locally on my machine. > > The only thing I had to do was change the Alter to a Create. Would that be > your problem? > > If not, the only other thought that comes to mind is the PPT database the > one with the table to hold the trigger. IOW, does the db and table exist? > > Sorry I could not help more, > > Mark > > > On 8 June 2012 14:08, Gustav Brock wrote: > > > Hi all > > > > I'm new to triggers but I've managed to create this which works as > > intended: > > > > USE [PPT] > > GO > > /****** Object: Trigger [dbo].[T_VariantsTable_UTrig] Script Date: > > 06/08/2012 14:45:17 ******/ > > SET ANSI_NULLS ON > > GO > > SET QUOTED_IDENTIFIER ON > > GO > > -- ============================================================= > > -- Author: Gustav Brock > > -- Create date: 2012-06-08 > > -- Description: Update field Created to time of update of record > > -- ============================================================= > > ALTER TRIGGER [dbo].[T_VariantsTable_UTrig] > > ON [dbo].[VariantsTable] > > FOR UPDATE > > AS > > BEGIN > > -- SET NOCOUNT ON added to prevent extra result sets from > > -- interfering with SELECT statements. > > SET NOCOUNT ON; > > > > -- Insert statements for trigger here > > DECLARE @id INT > > DECLARE @now DATETIME > > > > -- Retrieve ID of changed record. > > SELECT @id = (SELECT ID FROM deleted) > > -- Get current time without milliseconds. > > SELECT @now = DATEADD(SECOND, DATEDIFF(SECOND, '20000101', GETDATE()), > > '20000101') > > > > UPDATE VariantsTable > > SET Changed = @now > > WHERE ID = @id > > END > > > > However, when I open this in SMMS, this line has the last part red > > underlined: > > > > ALTER TRIGGER [dbo].[T_VariantsTable_UTrig] > > > > stating: Invalid object name 'dbo.T_VariantsTable_UTrig' > > > > Why is that? > > I have another trigger created by the Access upsize wizard with similar > > code: > > > > ALTER TRIGGER [dbo].[T_VariantsTable_ITrig] > > > > and nothing is underlined here. > > > > /gustav From jwcolby at colbyconsulting.com Thu Jun 14 07:32:47 2012 From: jwcolby at colbyconsulting.com (jwcolby) Date: Thu, 14 Jun 2012 08:32:47 -0400 Subject: [dba-SQLServer] Random autonumber ID In-Reply-To: References: Message-ID: <4FD9D9EF.5020404@colbyconsulting.com> Gustav, Trivial? if there are two hundred tables each with a random auto PK and there are 100 child tables, then there are 200 tables to change the PK type of and 100 tables to change the FK in. The process involves modifying each parent table to add a new sequential PK field keeping the OLD PK, each child table to add a new "NewFK" keeping the OldFK, populating the new sequential PK in the parent, then running a query to update the NewFK field in the child, *then* finding and fixing every reference to the OldFK to now point to the NewFK in all queries and dynamic SQL statements in code. hen you rename the OkdPK and OldFK fields during testing. Then dropping those "Old" columns. The "trivialness" of it depends entirely on the situation on the ground so to speak, but it is decidedly not trivial. While I would never use random in a new table, without very good reason, I would never make a change back to sequential in a large database with very many random PKs. John W. Colby Colby Consulting Reality is what refuses to go away when you do not believe in it On 6/12/2012 11:06 AM, Gustav Brock wrote: > Hi John > > This, trivial and cumbersome. > > However, the client has accepted to move to sequential numbers. The reason for the random numbers were, that the column this way looked "different" when perusing the table. Not a very heavy argument, he admitted. > > /gustav > > >>>> jwcolby at colbyconsulting.com 12-06-12 16:20>>> > The problem is that in order to revert you have to manually rebuild the autonumber PKs by moving the > data into a new table with a new autonumber, plus the old "random" autonumber. You then have to > update all child tables with then new PK values. This is darned ugly and error prone. > > John W. Colby > Colby Consulting > > Reality is what refuses to go away > when you do not believe in it > > On 6/12/2012 5:27 AM, Gustav Brock wrote: >> Hi Mark >> >> Thanks, I didn't know that. >> >> By the way, I located this page: >> http://e-university.wisdomjobs.com/ms-access/chapter-1413-203/upsizing-access-to-sql-server.html >> >> which has a very good explanation of the pitfalls in the paragraph: >> "Replicated Databases and Random Autonumbers") >> >> This tells me that I once again should try to persuade the client to bite the bullet and revert to sequential IDs. >> >> /gustav >> >> >>>>> marklbreen at gmail.com 12-06-12 10:23>>> >> Hello Gustav, >> >> I think that SQL Server will automatically pick up at the largest number >> currently in the table and work away happily. If not, you can easily set >> the starting number for the new range using DBCC CHECKIDENT >> >> In fact, if the last random number was 547845714 you could make the next >> Identity Insert start at 6000000000 >> >> Mark > > _______________________________________________ > dba-SQLServer mailing list > dba-SQLServer at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/dba-sqlserver > http://www.databaseadvisors.com > > From gustav at cactus.dk Thu Jun 14 09:03:52 2012 From: gustav at cactus.dk (Gustav Brock) Date: Thu, 14 Jun 2012 16:03:52 +0200 Subject: [dba-SQLServer] Random autonumber ID Message-ID: Hi John You are right, but by trivial I meant "doesn't require much brain work, just sit down and do it" - which, I know, very well could take a long time, but the count of tables with random IDs is low as most have a normal sequential ID. /gustav >>> jwcolby at colbyconsulting.com 14-06-12 14:32 >>> Gustav, Trivial? if there are two hundred tables each with a random auto PK and there are 100 child tables, then there are 200 tables to change the PK type of and 100 tables to change the FK in. The process involves modifying each parent table to add a new sequential PK field keeping the OLD PK, each child table to add a new "NewFK" keeping the OldFK, populating the new sequential PK in the parent, then running a query to update the NewFK field in the child, *then* finding and fixing every reference to the OldFK to now point to the NewFK in all queries and dynamic SQL statements in code. hen you rename the OkdPK and OldFK fields during testing. Then dropping those "Old" columns. The "trivialness" of it depends entirely on the situation on the ground so to speak, but it is decidedly not trivial. While I would never use random in a new table, without very good reason, I would never make a change back to sequential in a large database with very many random PKs. John W. Colby Colby Consulting Reality is what refuses to go away when you do not believe in it On 6/12/2012 11:06 AM, Gustav Brock wrote: > Hi John > > This, trivial and cumbersome. > > However, the client has accepted to move to sequential numbers. The reason for the random numbers were, that the column this way looked "different" when perusing the table. Not a very heavy argument, he admitted. > > /gustav > > >>>> jwcolby at colbyconsulting.com 12-06-12 16:20>>> > The problem is that in order to revert you have to manually rebuild the autonumber PKs by moving the > data into a new table with a new autonumber, plus the old "random" autonumber. You then have to > update all child tables with then new PK values. This is darned ugly and error prone. > > John W. Colby > Colby Consulting > > Reality is what refuses to go away > when you do not believe in it > > On 6/12/2012 5:27 AM, Gustav Brock wrote: >> Hi Mark >> >> Thanks, I didn't know that. >> >> By the way, I located this page: >> http://e-university.wisdomjobs.com/ms-access/chapter-1413-203/upsizing-access-to-sql-server.html >> >> which has a very good explanation of the pitfalls in the paragraph: >> "Replicated Databases and Random Autonumbers") >> >> This tells me that I once again should try to persuade the client to bite the bullet and revert to sequential IDs. >> >> /gustav >> >> >>>>> marklbreen at gmail.com 12-06-12 10:23>>> >> Hello Gustav, >> >> I think that SQL Server will automatically pick up at the largest number >> currently in the table and work away happily. If not, you can easily set >> the starting number for the new range using DBCC CHECKIDENT >> >> In fact, if the last random number was 547845714 you could make the next >> Identity Insert start at 6000000000 >> >> Mark From fhtapia at gmail.com Thu Jun 14 09:38:25 2012 From: fhtapia at gmail.com (Francisco Tapia) Date: Thu, 14 Jun 2012 07:38:25 -0700 Subject: [dba-SQLServer] Trigger syntax In-Reply-To: References: Message-ID: I've seen this issue in Management Studio before, you can fix most of these issues by right clicking on the object explorer on the grouping that you are working in and refresh, ( thanks microsoft! ) -Francisco http://bit.ly/sqlthis | Tsql and More... Let Apple know you want turn by turn on your iPhone 4! https://plus.google.com/112803888444646122406/posts/HmQej9pHZQM On Tue, Jun 12, 2012 at 1:39 AM, Gustav Brock wrote: > Hi Jim > > Yes, nothing fancy. And besides, the trigger works fine. > > I guess somehow the new trigger, though saved and working, was not > recognised by its name as a member of the collection by the intellisense > until a reboot had happened. > > /gustav > > > >>> accessd at shaw.ca 11-06-12 19:14 >>> > Hi Gustav: > > Have set up all the permissions right? > > Jim > > -----Original Message----- > From: dba-sqlserver-bounces at databaseadvisors.com > [mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Gustav > Brock > Sent: Monday, June 11, 2012 4:10 AM > To: dba-sqlserver at databaseadvisors.com > Subject: Re: [dba-SQLServer] Trigger syntax > > Hi Mark > > The code below was the code generated by the SQL template which is created > when you add a new trigger. > As you know, when you run the SQL containing "CREATE ...", the trigger > itself containing "ALTER ..." is created. > A trigger for Insert already existed. It is named > [dbo].[T_VariantsTable_ITrig]. > That's why I chose the name [dbo].[T_VariantsTable_UTrig] for my Update > trigger. > > However, this morning - after my workstation had been closed down for the > weekend - the issue has vanished. So, for some reason, the new trigger > hadn't been saved in full - or what? I really did logout and login again > several times and refreshed "everything". But no reboot. Is that really > needed? > > /gustav > > > >>> marklbreen at gmail.com 11-06-12 10:33 >>> > Hello Gustav > > I just copied your code into SSMS, change the two table names and it > worked. It created a trigger on a db here locally on my machine. > > The only thing I had to do was change the Alter to a Create. Would that be > your problem? > > If not, the only other thought that comes to mind is the PPT database the > one with the table to hold the trigger. IOW, does the db and table exist? > > Sorry I could not help more, > > Mark > > > On 8 June 2012 14:08, Gustav Brock wrote: > > > Hi all > > > > I'm new to triggers but I've managed to create this which works as > > intended: > > > > USE [PPT] > > GO > > /****** Object: Trigger [dbo].[T_VariantsTable_UTrig] Script Date: > > 06/08/2012 14:45:17 ******/ > > SET ANSI_NULLS ON > > GO > > SET QUOTED_IDENTIFIER ON > > GO > > -- ============================================================= > > -- Author: Gustav Brock > > -- Create date: 2012-06-08 > > -- Description: Update field Created to time of update of record > > -- ============================================================= > > ALTER TRIGGER [dbo].[T_VariantsTable_UTrig] > > ON [dbo].[VariantsTable] > > FOR UPDATE > > AS > > BEGIN > > -- SET NOCOUNT ON added to prevent extra result sets from > > -- interfering with SELECT statements. > > SET NOCOUNT ON; > > > > -- Insert statements for trigger here > > DECLARE @id INT > > DECLARE @now DATETIME > > > > -- Retrieve ID of changed record. > > SELECT @id = (SELECT ID FROM deleted) > > -- Get current time without milliseconds. > > SELECT @now = DATEADD(SECOND, DATEDIFF(SECOND, '20000101', GETDATE()), > > '20000101') > > > > UPDATE VariantsTable > > SET Changed = @now > > WHERE ID = @id > > END > > > > However, when I open this in SMMS, this line has the last part red > > underlined: > > > > ALTER TRIGGER [dbo].[T_VariantsTable_UTrig] > > > > stating: Invalid object name 'dbo.T_VariantsTable_UTrig' > > > > Why is that? > > I have another trigger created by the Access upsize wizard with similar > > code: > > > > ALTER TRIGGER [dbo].[T_VariantsTable_ITrig] > > > > and nothing is underlined here. > > > > /gustav > > > _______________________________________________ > dba-SQLServer mailing list > dba-SQLServer at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/dba-sqlserver > http://www.databaseadvisors.com > > From fhtapia at gmail.com Thu Jun 14 09:45:19 2012 From: fhtapia at gmail.com (Francisco Tapia) Date: Thu, 14 Jun 2012 07:45:19 -0700 Subject: [dba-SQLServer] Trigger syntax In-Reply-To: References: Message-ID: Gustav, First disable the intellisense in ssms http://sqlserver.ro/blogs/cristians_blog/archive/2007/11/20/turning-off-intellisense-in-sql-server-2008-ctp5.aspx Go to the redgate site and checkout sql prompt http://www.red-gate.com/products/sql-development/sql-prompt/ try the trialware for the 14 days (you can auto-extend the trial once expired by typing in I need more time and it gives you another 14 days). I think you'll like sql prompt, it's a real working intellisense, and just like in .net it works really well -Francisco http://bit.ly/sqlthis | Tsql and More... Let Apple know you want turn by turn on your iPhone 4! https://plus.google.com/112803888444646122406/posts/HmQej9pHZQM On Thu, Jun 14, 2012 at 3:17 AM, Gustav Brock wrote: > Hi Mark > > No, I use SSMS. > > /gustav > > > >>> marklbreen at gmail.com 14-06-12 11:30 >>> > Hello Gustav, > > Oh yes, the intellisense can cause a lot of hassle chasing a syntax error > that does not exist. > > Do you use SQL Prompt by Redgate? > > Mark > > > On 12 June 2012 09:39, Gustav Brock wrote: > > > Hi Jim > > > > Yes, nothing fancy. And besides, the trigger works fine. > > > > I guess somehow the new trigger, though saved and working, was not > > recognised by its name as a member of the collection by the intellisense > > until a reboot had happened. > > > > /gustav > > > > > > >>> accessd at shaw.ca 11-06-12 19:14 >>> > > Hi Gustav: > > > > Have set up all the permissions right? > > > > Jim > > > > -----Original Message----- > > From: dba-sqlserver-bounces at databaseadvisors.com > > [mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Gustav > > Brock > > Sent: Monday, June 11, 2012 4:10 AM > > To: dba-sqlserver at databaseadvisors.com > > Subject: Re: [dba-SQLServer] Trigger syntax > > > > Hi Mark > > > > The code below was the code generated by the SQL template which is > created > > when you add a new trigger. > > As you know, when you run the SQL containing "CREATE ...", the trigger > > itself containing "ALTER ..." is created. > > A trigger for Insert already existed. It is named > > [dbo].[T_VariantsTable_ITrig]. > > That's why I chose the name [dbo].[T_VariantsTable_UTrig] for my Update > > trigger. > > > > However, this morning - after my workstation had been closed down for the > > weekend - the issue has vanished. So, for some reason, the new trigger > > hadn't been saved in full - or what? I really did logout and login again > > several times and refreshed "everything". But no reboot. Is that really > > needed? > > > > /gustav > > > > > > >>> marklbreen at gmail.com 11-06-12 10:33 >>> > > Hello Gustav > > > > I just copied your code into SSMS, change the two table names and it > > worked. It created a trigger on a db here locally on my machine. > > > > The only thing I had to do was change the Alter to a Create. Would that > be > > your problem? > > > > If not, the only other thought that comes to mind is the PPT database the > > one with the table to hold the trigger. IOW, does the db and table > exist? > > > > Sorry I could not help more, > > > > Mark > > > > > > On 8 June 2012 14:08, Gustav Brock wrote: > > > > > Hi all > > > > > > I'm new to triggers but I've managed to create this which works as > > > intended: > > > > > > USE [PPT] > > > GO > > > /****** Object: Trigger [dbo].[T_VariantsTable_UTrig] Script Date: > > > 06/08/2012 14:45:17 ******/ > > > SET ANSI_NULLS ON > > > GO > > > SET QUOTED_IDENTIFIER ON > > > GO > > > -- ============================================================= > > > -- Author: Gustav Brock > > > -- Create date: 2012-06-08 > > > -- Description: Update field Created to time of update of record > > > -- ============================================================= > > > ALTER TRIGGER [dbo].[T_VariantsTable_UTrig] > > > ON [dbo].[VariantsTable] > > > FOR UPDATE > > > AS > > > BEGIN > > > -- SET NOCOUNT ON added to prevent extra result sets from > > > -- interfering with SELECT statements. > > > SET NOCOUNT ON; > > > > > > -- Insert statements for trigger here > > > DECLARE @id INT > > > DECLARE @now DATETIME > > > > > > -- Retrieve ID of changed record. > > > SELECT @id = (SELECT ID FROM deleted) > > > -- Get current time without milliseconds. > > > SELECT @now = DATEADD(SECOND, DATEDIFF(SECOND, '20000101', > GETDATE()), > > > '20000101') > > > > > > UPDATE VariantsTable > > > SET Changed = @now > > > WHERE ID = @id > > > END > > > > > > However, when I open this in SMMS, this line has the last part red > > > underlined: > > > > > > ALTER TRIGGER [dbo].[T_VariantsTable_UTrig] > > > > > > stating: Invalid object name 'dbo.T_VariantsTable_UTrig' > > > > > > Why is that? > > > I have another trigger created by the Access upsize wizard with similar > > > code: > > > > > > ALTER TRIGGER [dbo].[T_VariantsTable_ITrig] > > > > > > and nothing is underlined here. > > > > > > /gustav > > _______________________________________________ > dba-SQLServer mailing list > dba-SQLServer at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/dba-sqlserver > http://www.databaseadvisors.com > > From gustav at cactus.dk Thu Jun 14 10:19:04 2012 From: gustav at cactus.dk (Gustav Brock) Date: Thu, 14 Jun 2012 17:19:04 +0200 Subject: [dba-SQLServer] Trigger syntax Message-ID: Hi Francisco Oh, I did refresh "everything" multiple times, even disconnecting and relaunching SSMS. A bit strange as the created trigger was clearly listed in the object browser. Thanks for the tip on Redgate. /gustav >>> fhtapia at gmail.com 14-06-12 16:38 >>> I've seen this issue in Management Studio before, you can fix most of these issues by right clicking on the object explorer on the grouping that you are working in and refresh, ( thanks microsoft! ) -Francisco http://bit.ly/sqlthis | Tsql and More... Let Apple know you want turn by turn on your iPhone 4! https://plus.google.com/112803888444646122406/posts/HmQej9pHZQM On Tue, Jun 12, 2012 at 1:39 AM, Gustav Brock wrote: > Hi Jim > > Yes, nothing fancy. And besides, the trigger works fine. > > I guess somehow the new trigger, though saved and working, was not > recognised by its name as a member of the collection by the intellisense > until a reboot had happened. > > /gustav > > > >>> accessd at shaw.ca 11-06-12 19:14 >>> > Hi Gustav: > > Have set up all the permissions right? > > Jim > > -----Original Message----- > From: dba-sqlserver-bounces at databaseadvisors.com > [mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Gustav > Brock > Sent: Monday, June 11, 2012 4:10 AM > To: dba-sqlserver at databaseadvisors.com > Subject: Re: [dba-SQLServer] Trigger syntax > > Hi Mark > > The code below was the code generated by the SQL template which is created > when you add a new trigger. > As you know, when you run the SQL containing "CREATE ...", the trigger > itself containing "ALTER ..." is created. > A trigger for Insert already existed. It is named > [dbo].[T_VariantsTable_ITrig]. > That's why I chose the name [dbo].[T_VariantsTable_UTrig] for my Update > trigger. > > However, this morning - after my workstation had been closed down for the > weekend - the issue has vanished. So, for some reason, the new trigger > hadn't been saved in full - or what? I really did logout and login again > several times and refreshed "everything". But no reboot. Is that really > needed? > > /gustav > > > >>> marklbreen at gmail.com 11-06-12 10:33 >>> > Hello Gustav > > I just copied your code into SSMS, change the two table names and it > worked. It created a trigger on a db here locally on my machine. > > The only thing I had to do was change the Alter to a Create. Would that be > your problem? > > If not, the only other thought that comes to mind is the PPT database the > one with the table to hold the trigger. IOW, does the db and table exist? > > Sorry I could not help more, > > Mark > > > On 8 June 2012 14:08, Gustav Brock wrote: > > > Hi all > > > > I'm new to triggers but I've managed to create this which works as > > intended: > > > > USE [PPT] > > GO > > /****** Object: Trigger [dbo].[T_VariantsTable_UTrig] Script Date: > > 06/08/2012 14:45:17 ******/ > > SET ANSI_NULLS ON > > GO > > SET QUOTED_IDENTIFIER ON > > GO > > -- ============================================================= > > -- Author: Gustav Brock > > -- Create date: 2012-06-08 > > -- Description: Update field Created to time of update of record > > -- ============================================================= > > ALTER TRIGGER [dbo].[T_VariantsTable_UTrig] > > ON [dbo].[VariantsTable] > > FOR UPDATE > > AS > > BEGIN > > -- SET NOCOUNT ON added to prevent extra result sets from > > -- interfering with SELECT statements. > > SET NOCOUNT ON; > > > > -- Insert statements for trigger here > > DECLARE @id INT > > DECLARE @now DATETIME > > > > -- Retrieve ID of changed record. > > SELECT @id = (SELECT ID FROM deleted) > > -- Get current time without milliseconds. > > SELECT @now = DATEADD(SECOND, DATEDIFF(SECOND, '20000101', GETDATE()), > > '20000101') > > > > UPDATE VariantsTable > > SET Changed = @now > > WHERE ID = @id > > END > > > > However, when I open this in SMMS, this line has the last part red > > underlined: > > > > ALTER TRIGGER [dbo].[T_VariantsTable_UTrig] > > > > stating: Invalid object name 'dbo.T_VariantsTable_UTrig' > > > > Why is that? > > I have another trigger created by the Access upsize wizard with similar > > code: > > > > ALTER TRIGGER [dbo].[T_VariantsTable_ITrig] > > > > and nothing is underlined here. > > > > /gustav From accessd at shaw.ca Thu Jun 14 12:11:46 2012 From: accessd at shaw.ca (Jim Lawrence) Date: Thu, 14 Jun 2012 10:11:46 -0700 Subject: [dba-SQLServer] Random autonumber ID In-Reply-To: References: Message-ID: Just finished a small task asked for by a client. They wanted a running digital clock display to appear at the top right hand corner of each of their forms. Once the code was build it was really easy. But; it took me threes solid days to add it to all their modules and forms. Jim -----Original Message----- From: dba-sqlserver-bounces at databaseadvisors.com [mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Gustav Brock Sent: Thursday, June 14, 2012 7:04 AM To: dba-sqlserver at databaseadvisors.com Subject: Re: [dba-SQLServer] Random autonumber ID Hi John You are right, but by trivial I meant "doesn't require much brain work, just sit down and do it" - which, I know, very well could take a long time, but the count of tables with random IDs is low as most have a normal sequential ID. /gustav >>> jwcolby at colbyconsulting.com 14-06-12 14:32 >>> Gustav, Trivial? if there are two hundred tables each with a random auto PK and there are 100 child tables, then there are 200 tables to change the PK type of and 100 tables to change the FK in. The process involves modifying each parent table to add a new sequential PK field keeping the OLD PK, each child table to add a new "NewFK" keeping the OldFK, populating the new sequential PK in the parent, then running a query to update the NewFK field in the child, *then* finding and fixing every reference to the OldFK to now point to the NewFK in all queries and dynamic SQL statements in code. hen you rename the OkdPK and OldFK fields during testing. Then dropping those "Old" columns. The "trivialness" of it depends entirely on the situation on the ground so to speak, but it is decidedly not trivial. While I would never use random in a new table, without very good reason, I would never make a change back to sequential in a large database with very many random PKs. John W. Colby Colby Consulting Reality is what refuses to go away when you do not believe in it On 6/12/2012 11:06 AM, Gustav Brock wrote: > Hi John > > This, trivial and cumbersome. > > However, the client has accepted to move to sequential numbers. The reason for the random numbers were, that the column this way looked "different" when perusing the table. Not a very heavy argument, he admitted. > > /gustav > > >>>> jwcolby at colbyconsulting.com 12-06-12 16:20>>> > The problem is that in order to revert you have to manually rebuild the autonumber PKs by moving the > data into a new table with a new autonumber, plus the old "random" autonumber. You then have to > update all child tables with then new PK values. This is darned ugly and error prone. > > John W. Colby > Colby Consulting > > Reality is what refuses to go away > when you do not believe in it > > On 6/12/2012 5:27 AM, Gustav Brock wrote: >> Hi Mark >> >> Thanks, I didn't know that. >> >> By the way, I located this page: >> http://e-university.wisdomjobs.com/ms-access/chapter-1413-203/upsizing-acces s-to-sql-server.html >> >> which has a very good explanation of the pitfalls in the paragraph: >> "Replicated Databases and Random Autonumbers") >> >> This tells me that I once again should try to persuade the client to bite the bullet and revert to sequential IDs. >> >> /gustav >> >> >>>>> marklbreen at gmail.com 12-06-12 10:23>>> >> Hello Gustav, >> >> I think that SQL Server will automatically pick up at the largest number >> currently in the table and work away happily. If not, you can easily set >> the starting number for the new range using DBCC CHECKIDENT >> >> In fact, if the last random number was 547845714 you could make the next >> Identity Insert start at 6000000000 >> >> Mark _______________________________________________ dba-SQLServer mailing list dba-SQLServer at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/dba-sqlserver http://www.databaseadvisors.com From gustav at cactus.dk Fri Jun 15 01:49:22 2012 From: gustav at cactus.dk (Gustav Brock) Date: Fri, 15 Jun 2012 08:49:22 +0200 Subject: [dba-SQLServer] Replicate to laptop Message-ID: Hi all Our client asks for an option to replicate data between the central database and a local database on the user's laptop where an Access 2010 app is the frontend. The users are travelling purchasers, and the requirement is an option to hook up the laptop in the morning while at the hotel and sync, visit the suppliers where the laptop may be off-line, and return in the evening syncing again. They travel all over the World, so "morning" and "evening" are local times, thus I cannot count on "windows" or quiet hours. As the central database is SQL Server 2008 and the database size is well within the limits of SQL Server Express, my first thought was to install a local copy of SQL Server Express and set up replication between the central server and these local servers. But I haven't dealt with replication and SQL Server before, so I wonder if this is as simple as it sounds? Is this a no-brainer (just look up the BOL, as JC would say (not)), or are there any pitfalls, tips, or perhaps better methods? /gustav From jwcolby at colbyconsulting.com Sat Jun 16 09:53:20 2012 From: jwcolby at colbyconsulting.com (jwcolby) Date: Sat, 16 Jun 2012 10:53:20 -0400 Subject: [dba-SQLServer] How to troubleshoot a blue screen Message-ID: <4FDC9DE0.1090306@colbyconsulting.com> My SQL Server blue screens about once a month or so. It does not appear to be heat related, or at least CPU heat related as I have top flight HSFs which hold the temps below 35 C. The temps in the case stay around that temperature or below. The blue screens appear to be SQL Server related, as they seem to be triggered by my doing something in SSMS. This last time I started an update query and it immediately blue screened, by which I mean I clicked start (the query) and the blue screen occurred. This is an AMD dual cpu server, both CPUs populated. 32 gigs ECC RAM on each side. Being a server there is no overclocking. There is a lot going on hardware wise however. I use an Areca 16 port RAID controller, RAID 6 arrays built from 1 tb WD black drives. I am using SSDs to create a Raid1 array hosting several of my Read Mostly databases. The specific update that caused the blue screen was not on SSD however, it was on the Areca rotating media raid 6. I am at a loss on how to troubleshoot. It "feels" like it must be a memory problem, and yet the memory is ECC. Perhaps I have a bad DIMM which just flakes out. -- John W. Colby Colby Consulting Reality is what refuses to go away when you do not believe in it From fhtapia at gmail.com Tue Jun 19 08:17:40 2012 From: fhtapia at gmail.com (Francisco Tapia) Date: Tue, 19 Jun 2012 06:17:40 -0700 Subject: [dba-SQLServer] How to troubleshoot a blue screen In-Reply-To: <4FDC9DE0.1090306@colbyconsulting.com> References: <4FDC9DE0.1090306@colbyconsulting.com> Message-ID: if you have some time, you can test the RAM easily by just downloading the memtest application to a cd rom boot to it let it run for a few hours, if it's ram related it'll show up in the monitor. http://www.memtest.org/ -Francisco http://bit.ly/sqlthis | Tsql and More... Let Apple know you want turn by turn on your iPhone 4! https://plus.google.com/112803888444646122406/posts/HmQej9pHZQM On Sat, Jun 16, 2012 at 7:53 AM, jwcolby wrote: > My SQL Server blue screens about once a month or so. It does not appear > to be heat related, or at least CPU heat related as I have top flight HSFs > which hold the temps below 35 C. The temps in the case stay around that > temperature or below. The blue screens appear to be SQL Server related, as > they seem to be triggered by my doing something in SSMS. This last time I > started an update query and it immediately blue screened, by which I mean I > clicked start (the query) and the blue screen occurred. > > This is an AMD dual cpu server, both CPUs populated. 32 gigs ECC RAM on > each side. Being a server there is no overclocking. There is a lot going > on hardware wise however. I use an Areca 16 port RAID controller, RAID 6 > arrays built from 1 tb WD black drives. I am using SSDs to create a Raid1 > array hosting several of my Read Mostly databases. The specific update > that caused the blue screen was not on SSD however, it was on the Areca > rotating media raid 6. > > I am at a loss on how to troubleshoot. It "feels" like it must be a > memory problem, and yet the memory is ECC. Perhaps I have a bad DIMM which > just flakes out. > > -- > John W. Colby > Colby Consulting > > Reality is what refuses to go away > when you do not believe in it > > > ______________________________**_________________ > dba-SQLServer mailing list > dba-SQLServer@**databaseadvisors.com > http://databaseadvisors.com/**mailman/listinfo/dba-sqlserver > http://www.databaseadvisors.**com > > From fhtapia at gmail.com Tue Jun 19 08:37:48 2012 From: fhtapia at gmail.com (Francisco Tapia) Date: Tue, 19 Jun 2012 06:37:48 -0700 Subject: [dba-SQLServer] Replicate to laptop In-Reply-To: References: Message-ID: Gustav, I haven't worked on replication in a long time but I had a project several years ago that made use of replication, in Sql Express there are no Sql Agents (that I'm aware of) and thus you'll need to run the pull subscription to your express db via programming check out this MS link to get you on your way... http://msdn.microsoft.com/en-us/library/ms147314%28v=sql.100%29.aspx -Francisco http://bit.ly/sqlthis | Tsql and More... Let Apple know you want turn by turn on your iPhone 4! https://plus.google.com/112803888444646122406/posts/HmQej9pHZQM On Thu, Jun 14, 2012 at 11:49 PM, Gustav Brock wrote: > Hi all > > Our client asks for an option to replicate data between the central > database and a local database on the user's laptop where an Access 2010 app > is the frontend. > > The users are travelling purchasers, and the requirement is an option to > hook up the laptop in the morning while at the hotel and sync, visit the > suppliers where the laptop may be off-line, and return in the evening > syncing again. They travel all over the World, so "morning" and "evening" > are local times, thus I cannot count on "windows" or quiet hours. > > As the central database is SQL Server 2008 and the database size is well > within the limits of SQL Server Express, my first thought was to install a > local copy of SQL Server Express and set up replication between the central > server and these local servers. > > But I haven't dealt with replication and SQL Server before, so I wonder if > this is as simple as it sounds? Is this a no-brainer (just look up the BOL, > as JC would say (not)), or are there any pitfalls, tips, or perhaps better > methods? > > /gustav > > _______________________________________________ > dba-SQLServer mailing list > dba-SQLServer at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/dba-sqlserver > http://www.databaseadvisors.com > > From jwcolby at colbyconsulting.com Tue Jun 19 11:54:24 2012 From: jwcolby at colbyconsulting.com (jwcolby) Date: Tue, 19 Jun 2012 12:54:24 -0400 Subject: [dba-SQLServer] How to troubleshoot a blue screen In-Reply-To: References: <4FDC9DE0.1090306@colbyconsulting.com> Message-ID: <4FE0AEC0.9050005@colbyconsulting.com> Yea, and I am going to do that. With 64 gigs of memory it will be more than "a few hours"! ;) It may be that the problem was a SSD which died Monday morning. John W. Colby Colby Consulting Reality is what refuses to go away when you do not believe in it On 6/19/2012 9:17 AM, Francisco Tapia wrote: > if you have some time, you can test the RAM easily by just downloading the > memtest application to a cd rom boot to it let it run for a few hours, if > it's ram related it'll show up in the monitor. > > http://www.memtest.org/ > > > > -Francisco > http://bit.ly/sqlthis | Tsql and More... > Let Apple know you want turn by turn on your iPhone 4! > https://plus.google.com/112803888444646122406/posts/HmQej9pHZQM > > > > > > > On Sat, Jun 16, 2012 at 7:53 AM, jwcolby wrote: > >> My SQL Server blue screens about once a month or so. It does not appear >> to be heat related, or at least CPU heat related as I have top flight HSFs >> which hold the temps below 35 C. The temps in the case stay around that >> temperature or below. The blue screens appear to be SQL Server related, as >> they seem to be triggered by my doing something in SSMS. This last time I >> started an update query and it immediately blue screened, by which I mean I >> clicked start (the query) and the blue screen occurred. >> >> This is an AMD dual cpu server, both CPUs populated. 32 gigs ECC RAM on >> each side. Being a server there is no overclocking. There is a lot going >> on hardware wise however. I use an Areca 16 port RAID controller, RAID 6 >> arrays built from 1 tb WD black drives. I am using SSDs to create a Raid1 >> array hosting several of my Read Mostly databases. The specific update >> that caused the blue screen was not on SSD however, it was on the Areca >> rotating media raid 6. >> >> I am at a loss on how to troubleshoot. It "feels" like it must be a >> memory problem, and yet the memory is ECC. Perhaps I have a bad DIMM which >> just flakes out. >> >> -- >> John W. Colby >> Colby Consulting >> >> Reality is what refuses to go away >> when you do not believe in it >> >> >> ______________________________**_________________ >> dba-SQLServer mailing list >> dba-SQLServer@**databaseadvisors.com >> http://databaseadvisors.com/**mailman/listinfo/dba-sqlserver >> http://www.databaseadvisors.**com >> >> > _______________________________________________ > dba-SQLServer mailing list > dba-SQLServer at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/dba-sqlserver > http://www.databaseadvisors.com > > From fhtapia at gmail.com Tue Jun 19 13:02:26 2012 From: fhtapia at gmail.com (Francisco Tapia) Date: Tue, 19 Jun 2012 11:02:26 -0700 Subject: [dba-SQLServer] How to troubleshoot a blue screen In-Reply-To: <4FE0AEC0.9050005@colbyconsulting.com> References: <4FDC9DE0.1090306@colbyconsulting.com> <4FE0AEC0.9050005@colbyconsulting.com> Message-ID: LOL, well Ram is fast, and it doesn't take that long to run a test (be it 64gb or not) the cycle test is what can take some time, but a few hours would suffice for letting you know if there are any errors. you only really need to do the full cycles if you want to ensure that it's fully burned in, something you've already taken care of. http://forum.notebookreview.com/notebook-dummy-guide-articles/142746-testing-your-ram-memtest86.html (steps for memtest+) Memtest86+ is very easy to use. All you need to do is: 1. Download the file. I'm going to walk through using the "Pre-Compiled Bootable ISO (.zip)" file. You can get that from this page . 2. Unzip the file. There's only 1 file in there, called "memtest86+-X.YY.iso" 3. Burn the ISO file to CD. This is the potentially tricky part. An ISO file is a disc image, and cannot be burned directly to a CD. Your CD recording tool should have an option like "Burn image to CD" or something like that. If you can't find it, you can try the free ISO Recorderpowertoy. After you burn the CD, if you put it back in the drive and see the file "memtest86+-X.YY.iso" listed, you've done it wrong 4. Shut down your computer completely, then unplug it. *DO NOT DO THIS IN SLEEP OR HIBERNATE MODE!!!* 5. I recommend testing the modules one at a time, so if one is bad, it's easy to know which one! Take out all but one of the RAM modules. 6. Plug in the computer, put the CD in the drive and reboot. Make sure it boots off the CD, not the hard drive. You should see a blue screen with a green bar on the top that says: "Memtest86+". There are screen shots on the memtest86+ web site so you can get an idea. 7. Now, you wait for the test! The test will *run forever* until you stop it. You should run it for at least 1 full pass, more if you have the time. 8. Once the test is done for that RAM module, shut down, unplug, take out the module you just tested, put in the new one, and test again. so not a lot of time, and iirc the test will tell you wich bank failed if there is an error (but if you don't know your board well enough testing one at a time will save headaches). -Francisco http://bit.ly/sqlthis | Tsql and More... Let Apple know you want turn by turn on your iPhone 4! https://plus.google.com/112803888444646122406/posts/HmQej9pHZQM On Tue, Jun 19, 2012 at 9:54 AM, jwcolby wrote: > Yea, and I am going to do that. With 64 gigs of memory it will be more > than "a few hours"! ;) > > It may be that the problem was a SSD which died Monday morning. > > > John W. Colby > Colby Consulting > > Reality is what refuses to go away > when you do not believe in it > > > On 6/19/2012 9:17 AM, Francisco Tapia wrote: > >> if you have some time, you can test the RAM easily by just downloading the >> memtest application to a cd rom boot to it let it run for a few hours, if >> it's ram related it'll show up in the monitor. >> >> http://www.memtest.org/ >> >> >> >> -Francisco >> http://bit.ly/sqlthis | Tsql and More... >> Let Apple know you want turn by turn on your iPhone 4! >> https://plus.google.com/**112803888444646122406/posts/**HmQej9pHZQM >> >> >> >> >> >> >> >> On Sat, Jun 16, 2012 at 7:53 AM, jwcolby ** >> wrote: >> >> My SQL Server blue screens about once a month or so. It does not appear >>> to be heat related, or at least CPU heat related as I have top flight >>> HSFs >>> which hold the temps below 35 C. The temps in the case stay around that >>> temperature or below. The blue screens appear to be SQL Server related, >>> as >>> they seem to be triggered by my doing something in SSMS. This last time >>> I >>> started an update query and it immediately blue screened, by which I >>> mean I >>> clicked start (the query) and the blue screen occurred. >>> >>> This is an AMD dual cpu server, both CPUs populated. 32 gigs ECC RAM on >>> each side. Being a server there is no overclocking. There is a lot >>> going >>> on hardware wise however. I use an Areca 16 port RAID controller, RAID 6 >>> arrays built from 1 tb WD black drives. I am using SSDs to create a >>> Raid1 >>> array hosting several of my Read Mostly databases. The specific update >>> that caused the blue screen was not on SSD however, it was on the Areca >>> rotating media raid 6. >>> >>> I am at a loss on how to troubleshoot. It "feels" like it must be a >>> memory problem, and yet the memory is ECC. Perhaps I have a bad DIMM >>> which >>> just flakes out. >>> >>> -- >>> John W. Colby >>> Colby Consulting >>> >>> Reality is what refuses to go away >>> when you do not believe in it >>> >>> >>> ______________________________****_________________ >>> dba-SQLServer mailing list >>> dba-SQLServer@**databaseadviso**rs.com < >>> dba-SQLServer@**databaseadvisors.com >>> > >>> http://databaseadvisors.com/****mailman/listinfo/dba-sqlserver >>> ** >>> **> >>> http://www.databaseadvisors.****com >>> > >>> >>> >>> ______________________________**_________________ >> dba-SQLServer mailing list >> dba-SQLServer@**databaseadvisors.com >> http://databaseadvisors.com/**mailman/listinfo/dba-sqlserver >> http://www.databaseadvisors.**com >> >> >> > > ______________________________**_________________ > dba-SQLServer mailing list > dba-SQLServer@**databaseadvisors.com > http://databaseadvisors.com/**mailman/listinfo/dba-sqlserver > http://www.databaseadvisors.**com > > From jwcolby at colbyconsulting.com Tue Jun 19 15:27:42 2012 From: jwcolby at colbyconsulting.com (jwcolby) Date: Tue, 19 Jun 2012 16:27:42 -0400 Subject: [dba-SQLServer] How to troubleshoot a blue screen In-Reply-To: References: <4FDC9DE0.1090306@colbyconsulting.com> <4FE0AEC0.9050005@colbyconsulting.com> Message-ID: <4FE0E0BE.2010701@colbyconsulting.com> I have used Memtest64 dozens of times over the years. Yes any single "can I access the memory at all" test only takes a "little while", however to do the full set of tests (adjacent bits, patterns and so forth) is not fast. Furthermore the memory is ECC memory anyway. I have no idea what Memtest86 is going to do with that. If there is an occasional error the ECC circuitry is supposed to handle it automatically and not even report it to MemTest86. I believe that the issue is probably a disk dying. Now when it blue screens it fails to post, giving errors about talking to SATA channel 3. It seems I was silly enough to try and use an SSD for my boot disk. I have migrated the boot to a rotating disk and am back to work. The only way I will know is if the blue screens stop occurring. John W. Colby Colby Consulting Reality is what refuses to go away when you do not believe in it On 6/19/2012 2:02 PM, Francisco Tapia wrote: > LOL, > well Ram is fast, and it doesn't take that long to run a test (be it 64gb > or not) the cycle test is what can take some time, but a few hours would > suffice for letting you know if there are any errors. you only really need > to do the full cycles if you want to ensure that it's fully burned in, > something you've already taken care of. > > http://forum.notebookreview.com/notebook-dummy-guide-articles/142746-testing-your-ram-memtest86.html > (steps for memtest+) > > Memtest86+ is very easy to use. All you need to do is: > > 1. Download the file. I'm going to walk through using the "Pre-Compiled > Bootable ISO (.zip)" file. You can get that from this > page > . > 2. Unzip the file. There's only 1 file in there, called > "memtest86+-X.YY.iso" > 3. Burn the ISO file to CD. This is the potentially tricky part. An ISO > file is a disc image, and cannot be burned directly to a CD. Your CD > recording tool should have an option like "Burn image to CD" or something > like that. If you can't find it, you can try the free ISO > Recorderpowertoy. > After you burn the CD, if you put it back in the drive and see > the file "memtest86+-X.YY.iso" listed, you've done it wrong > 4. Shut down your computer completely, then unplug it. *DO NOT DO THIS > IN SLEEP OR HIBERNATE MODE!!!* > 5. I recommend testing the modules one at a time, so if one is bad, it's > easy to know which one! Take out all but one of the RAM modules. > 6. Plug in the computer, put the CD in the drive and reboot. Make sure > it boots off the CD, not the hard drive. You should see a blue screen with > a green bar on the top that says: "Memtest86+". There are screen shots on > the memtest86+ web site so you can get > an idea. > 7. Now, you wait for the test! The test will *run forever* until you > stop it. You should run it for at least 1 full pass, more if you have the > time. > 8. Once the test is done for that RAM module, shut down, unplug, take > out the module you just tested, put in the new one, and test again. > > > > so not a lot of time, and iirc the test will tell you wich bank failed if > there is an error (but if you don't know your board well enough testing one > at a time will save headaches). > > > > -Francisco > http://bit.ly/sqlthis | Tsql and More... > Let Apple know you want turn by turn on your iPhone 4! > https://plus.google.com/112803888444646122406/posts/HmQej9pHZQM > > > > > > > On Tue, Jun 19, 2012 at 9:54 AM, jwcolby wrote: > >> Yea, and I am going to do that. With 64 gigs of memory it will be more >> than "a few hours"! ;) >> >> It may be that the problem was a SSD which died Monday morning. >> >> >> John W. Colby >> Colby Consulting >> >> Reality is what refuses to go away >> when you do not believe in it >> >> >> On 6/19/2012 9:17 AM, Francisco Tapia wrote: >> >>> if you have some time, you can test the RAM easily by just downloading the >>> memtest application to a cd rom boot to it let it run for a few hours, if >>> it's ram related it'll show up in the monitor. >>> >>> http://www.memtest.org/ >>> >>> >>> >>> -Francisco >>> http://bit.ly/sqlthis | Tsql and More... >>> Let Apple know you want turn by turn on your iPhone 4! >>> https://plus.google.com/**112803888444646122406/posts/**HmQej9pHZQM >>> >>> >>> >>> >>> >>> >>> >>> On Sat, Jun 16, 2012 at 7:53 AM, jwcolby ** >>> wrote: >>> >>> My SQL Server blue screens about once a month or so. It does not appear >>>> to be heat related, or at least CPU heat related as I have top flight >>>> HSFs >>>> which hold the temps below 35 C. The temps in the case stay around that >>>> temperature or below. The blue screens appear to be SQL Server related, >>>> as >>>> they seem to be triggered by my doing something in SSMS. This last time >>>> I >>>> started an update query and it immediately blue screened, by which I >>>> mean I >>>> clicked start (the query) and the blue screen occurred. >>>> >>>> This is an AMD dual cpu server, both CPUs populated. 32 gigs ECC RAM on >>>> each side. Being a server there is no overclocking. There is a lot >>>> going >>>> on hardware wise however. I use an Areca 16 port RAID controller, RAID 6 >>>> arrays built from 1 tb WD black drives. I am using SSDs to create a >>>> Raid1 >>>> array hosting several of my Read Mostly databases. The specific update >>>> that caused the blue screen was not on SSD however, it was on the Areca >>>> rotating media raid 6. >>>> >>>> I am at a loss on how to troubleshoot. It "feels" like it must be a >>>> memory problem, and yet the memory is ECC. Perhaps I have a bad DIMM >>>> which >>>> just flakes out. >>>> >>>> -- >>>> John W. Colby >>>> Colby Consulting >>>> >>>> Reality is what refuses to go away >>>> when you do not believe in it >>>> >>>> >>>> ______________________________****_________________ >>>> dba-SQLServer mailing list >>>> dba-SQLServer@**databaseadviso**rs.com < >>>> dba-SQLServer@**databaseadvisors.com >>>>> >>>> http://databaseadvisors.com/****mailman/listinfo/dba-sqlserver >>>> ** >>>> **> >>>> http://www.databaseadvisors.****com >>>>> >>>> >>>> >>>> ______________________________**_________________ >>> dba-SQLServer mailing list >>> dba-SQLServer@**databaseadvisors.com >>> http://databaseadvisors.com/**mailman/listinfo/dba-sqlserver >>> http://www.databaseadvisors.**com >>> >>> >>> >> >> ______________________________**_________________ >> dba-SQLServer mailing list >> dba-SQLServer@**databaseadvisors.com >> http://databaseadvisors.com/**mailman/listinfo/dba-sqlserver >> http://www.databaseadvisors.**com >> >> > _______________________________________________ > dba-SQLServer mailing list > dba-SQLServer at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/dba-sqlserver > http://www.databaseadvisors.com > > From jwcolby at colbyconsulting.com Tue Jun 19 15:34:53 2012 From: jwcolby at colbyconsulting.com (jwcolby) Date: Tue, 19 Jun 2012 16:34:53 -0400 Subject: [dba-SQLServer] Index on view Message-ID: <4FE0E26D.8070306@colbyconsulting.com> I have a pair of tables. Both tables have a clustered index on an integer PK. TableA the PK is an autonumber. TableB the PK is the PK from TableA, i.e. it is 1 to 1. TableA is updated monthly, TableA and TableB both get records added occasionally. I just added about 180 million records to both tables. I do occasionally delete records from both as the data ages. For providing counts to my client I need to join the two tables on the PK, then pull a single field from TableA and a handful of fields from TableB. From there I will be doing count / group by kind of things. I created a view to pull all of the fields used in these counts. I thought I would create an index on the view. Is this a good idea? I have never indexed a view but I know it is possible. -- John W. Colby Colby Consulting Reality is what refuses to go away when you do not believe in it From fhtapia at gmail.com Tue Jun 19 16:04:54 2012 From: fhtapia at gmail.com (Francisco Tapia) Date: Tue, 19 Jun 2012 14:04:54 -0700 Subject: [dba-SQLServer] How to troubleshoot a blue screen In-Reply-To: <4FE0E0BE.2010701@colbyconsulting.com> References: <4FDC9DE0.1090306@colbyconsulting.com> <4FE0AEC0.9050005@colbyconsulting.com> <4FE0E0BE.2010701@colbyconsulting.com> Message-ID: I don't have any issue with my boot disk being raid1, but it seems you're fixing your issue... happy times. -Francisco http://bit.ly/sqlthis | Tsql and More... Let Apple know you want turn by turn on your iPhone 4! https://plus.google.com/112803888444646122406/posts/HmQej9pHZQM On Tue, Jun 19, 2012 at 1:27 PM, jwcolby wrote: > I have used Memtest64 dozens of times over the years. Yes any single "can > I access the memory at all" test only takes a "little while", however to do > the full set of tests (adjacent bits, patterns and so forth) is not fast. > > Furthermore the memory is ECC memory anyway. I have no idea what > Memtest86 is going to do with that. If there is an occasional error the > ECC circuitry is supposed to handle it automatically and not even report it > to MemTest86. > > I believe that the issue is probably a disk dying. Now when it blue > screens it fails to post, giving errors about talking to SATA channel 3. > > It seems I was silly enough to try and use an SSD for my boot disk. I > have migrated the boot to a rotating disk and am back to work. The only > way I will know is if the blue screens stop occurring. > > > John W. Colby > Colby Consulting > > Reality is what refuses to go away > when you do not believe in it > > > On 6/19/2012 2:02 PM, Francisco Tapia wrote: > >> LOL, >> well Ram is fast, and it doesn't take that long to run a test (be it >> 64gb >> or not) the cycle test is what can take some time, but a few hours would >> suffice for letting you know if there are any errors. you only really >> need >> to do the full cycles if you want to ensure that it's fully burned in, >> something you've already taken care of. >> >> http://forum.notebookreview.**com/notebook-dummy-guide-** >> articles/142746-testing-your-**ram-memtest86.html >> (steps for memtest+) >> >> Memtest86+ is very easy to use. All you need to do is: >> >> 1. Download the file. I'm going to walk through using the "Pre-Compiled >> >> Bootable ISO (.zip)" file. You can get that from this >> page> >> . >> 2. Unzip the file. There's only 1 file in there, called >> "memtest86+-X.YY.iso" >> 3. Burn the ISO file to CD. This is the potentially tricky part. An ISO >> >> file is a disc image, and cannot be burned directly to a CD. Your CD >> recording tool should have an option like "Burn image to CD" or >> something >> like that. If you can't find it, you can try the free ISO >> Recorder >> >powertoy. >> >> After you burn the CD, if you put it back in the drive and see >> the file "memtest86+-X.YY.iso" listed, you've done it wrong >> 4. Shut down your computer completely, then unplug it. *DO NOT DO THIS >> IN SLEEP OR HIBERNATE MODE!!!* >> 5. I recommend testing the modules one at a time, so if one is bad, >> it's >> >> easy to know which one! Take out all but one of the RAM modules. >> 6. Plug in the computer, put the CD in the drive and reboot. Make sure >> >> it boots off the CD, not the hard drive. You should see a blue screen >> with >> a green bar on the top that says: "Memtest86+". There are screen shots >> on >> the memtest86+ web site > >> so you can get >> an idea. >> 7. Now, you wait for the test! The test will *run forever* until you >> >> stop it. You should run it for at least 1 full pass, more if you have >> the >> time. >> 8. Once the test is done for that RAM module, shut down, unplug, take >> >> out the module you just tested, put in the new one, and test again. >> >> >> >> so not a lot of time, and iirc the test will tell you wich bank failed if >> there is an error (but if you don't know your board well enough testing >> one >> at a time will save headaches). >> >> >> >> -Francisco >> http://bit.ly/sqlthis | Tsql and More... >> Let Apple know you want turn by turn on your iPhone 4! >> https://plus.google.com/**112803888444646122406/posts/**HmQej9pHZQM >> >> >> >> >> >> >> >> On Tue, Jun 19, 2012 at 9:54 AM, jwcolby ** >> wrote: >> >> Yea, and I am going to do that. With 64 gigs of memory it will be more >>> than "a few hours"! ;) >>> >>> It may be that the problem was a SSD which died Monday morning. >>> >>> >>> John W. Colby >>> Colby Consulting >>> >>> Reality is what refuses to go away >>> when you do not believe in it >>> >>> >>> On 6/19/2012 9:17 AM, Francisco Tapia wrote: >>> >>> if you have some time, you can test the RAM easily by just downloading >>>> the >>>> memtest application to a cd rom boot to it let it run for a few hours, >>>> if >>>> it's ram related it'll show up in the monitor. >>>> >>>> http://www.memtest.org/ >>>> >>>> >>>> >>>> -Francisco >>>> http://bit.ly/sqlthis | Tsql and More... >>>> Let Apple know you want turn by turn on your iPhone 4! >>>> https://plus.google.com/****112803888444646122406/posts/****HmQej9pHZQM >>>> >>>> > >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> On Sat, Jun 16, 2012 at 7:53 AM, jwcolby * >>>> *** >>>> >>>> wrote: >>>> >>>> My SQL Server blue screens about once a month or so. It does not >>>> appear >>>> >>>>> to be heat related, or at least CPU heat related as I have top flight >>>>> HSFs >>>>> which hold the temps below 35 C. The temps in the case stay around >>>>> that >>>>> temperature or below. The blue screens appear to be SQL Server >>>>> related, >>>>> as >>>>> they seem to be triggered by my doing something in SSMS. This last >>>>> time >>>>> I >>>>> started an update query and it immediately blue screened, by which I >>>>> mean I >>>>> clicked start (the query) and the blue screen occurred. >>>>> >>>>> This is an AMD dual cpu server, both CPUs populated. 32 gigs ECC RAM >>>>> on >>>>> each side. Being a server there is no overclocking. There is a lot >>>>> going >>>>> on hardware wise however. I use an Areca 16 port RAID controller, >>>>> RAID 6 >>>>> arrays built from 1 tb WD black drives. I am using SSDs to create a >>>>> Raid1 >>>>> array hosting several of my Read Mostly databases. The specific update >>>>> that caused the blue screen was not on SSD however, it was on the Areca >>>>> rotating media raid 6. >>>>> >>>>> I am at a loss on how to troubleshoot. It "feels" like it must be a >>>>> memory problem, and yet the memory is ECC. Perhaps I have a bad DIMM >>>>> which >>>>> just flakes out. >>>>> >>>>> -- >>>>> John W. Colby >>>>> Colby Consulting >>>>> >>>>> Reality is what refuses to go away >>>>> when you do not believe in it >>>>> >>>>> >>>>> ______________________________******_________________ >>>>> dba-SQLServer mailing list >>>>> dba-SQLServer@****databaseadviso**rs.com >>>>> < >>>>> dba-SQLServer@**databaseadviso**rs.com < >>>>> dba-SQLServer@**databaseadvisors.com >>>>> > >>>>> >>>>>> >>>>>> http://databaseadvisors.com/******mailman/listinfo/dba-**sqlserver >>>>> >>>>> **> >>>>> ** >>>>> >>>>> > >>>>> **> >>>>> http://www.databaseadvisors.******com >>>> *com >>>>> > >>>>> >>>>>> >>>>>> >>>>> >>>>> ______________________________****_________________ >>>>> >>>> dba-SQLServer mailing list >>>> dba-SQLServer@**databaseadviso**rs.com < >>>> dba-SQLServer@**databaseadvisors.com >>>> > >>>> http://databaseadvisors.com/****mailman/listinfo/dba-sqlserver >>>> ** >>>> **> >>>> http://www.databaseadvisors.****com >>>> > >>>> >>>> >>>> >>>> >>> ______________________________****_________________ >>> dba-SQLServer mailing list >>> dba-SQLServer@**databaseadviso**rs.com < >>> dba-SQLServer@**databaseadvisors.com >>> > >>> http://databaseadvisors.com/****mailman/listinfo/dba-sqlserver >>> ** >>> **> >>> http://www.databaseadvisors.****com >>> > >>> >>> >>> ______________________________**_________________ >> dba-SQLServer mailing list >> dba-SQLServer@**databaseadvisors.com >> http://databaseadvisors.com/**mailman/listinfo/dba-sqlserver >> http://www.databaseadvisors.**com >> >> >> > > ______________________________**_________________ > dba-SQLServer mailing list > dba-SQLServer@**databaseadvisors.com > http://databaseadvisors.com/**mailman/listinfo/dba-sqlserver > http://www.databaseadvisors.**com > > From marklbreen at gmail.com Wed Jun 20 02:56:23 2012 From: marklbreen at gmail.com (Mark Breen) Date: Wed, 20 Jun 2012 08:56:23 +0100 Subject: [dba-SQLServer] Index on view In-Reply-To: <4FE0E26D.8070306@colbyconsulting.com> References: <4FE0E26D.8070306@colbyconsulting.com> Message-ID: Hello John, I have no idea, but I would like to hear what your experiences are. I accidentally created an index on a view recently and I cannot report on performance, but I notice that it takes up space in the database. I try never to join on views, I have always found that to be terribly slow. I prefer to write one long SQL statement with nest joins. Do you ever use the Database Engine Tuning Advisor? Does it collapse when it sees your database? I used it recently and it suggested I create a bunch of compound indexes. It gave me some performance increases. Mark On 19 June 2012 21:34, jwcolby wrote: > I have a pair of tables. Both tables have a clustered index on an integer > PK. TableA the PK is an autonumber. TableB the PK is the PK from TableA, > i.e. it is 1 to 1. > > TableA is updated monthly, TableA and TableB both get records added > occasionally. I just added about 180 million records to both tables. I do > occasionally delete records from both as the data ages. > > For providing counts to my client I need to join the two tables on the PK, > then pull a single field from TableA and a handful of fields from TableB. > From there I will be doing count / group by kind of things. > > I created a view to pull all of the fields used in these counts. I > thought I would create an index on the view. > > Is this a good idea? I have never indexed a view but I know it is > possible. > > -- > John W. Colby > Colby Consulting > > Reality is what refuses to go away > when you do not believe in it > > > ______________________________**_________________ > dba-SQLServer mailing list > dba-SQLServer@**databaseadvisors.com > http://databaseadvisors.com/**mailman/listinfo/dba-sqlserver > http://www.databaseadvisors.**com > > From jwcolby at colbyconsulting.com Wed Jun 20 08:02:06 2012 From: jwcolby at colbyconsulting.com (jwcolby) Date: Wed, 20 Jun 2012 09:02:06 -0400 Subject: [dba-SQLServer] Index on view In-Reply-To: References: <4FE0E26D.8070306@colbyconsulting.com> Message-ID: <4FE1C9CE.1090607@colbyconsulting.com> I am creating a pair of indexes now. I apparently have to create a clustered index and then whatever other indexes I need. Why I am not sure but it refuses to create non-clustered indexes until the clustered index exists. I also use compression everywhere. Even though I have 64 gigs of memory, compression allows much more to fit into memory, and with 16 cores available, there are spare cores available to perform the decompression as data is used. > I try never to join on views, I have always found that to be terribly slow. I prefer to write one long SQL statement with nest joins. According to my reading, when this happens, SQL Server simply extracts all of the view metadata and builds up the equivalent of your "one long sql statement with nested joins". Of course there is the time required to analyze and perform that sql statement build so it would be somewhat slower on the front end. One would expect the actual query execution to be the same speed. John W. Colby Colby Consulting Reality is what refuses to go away when you do not believe in it On 6/20/2012 3:56 AM, Mark Breen wrote: > Hello John, > > I have no idea, but I would like to hear what your experiences are. > > I accidentally created an index on a view recently and I cannot report on > performance, but I notice that it takes up space in the database. > > I try never to join on views, I have always found that to be terribly slow. > I prefer to write one long SQL statement with nest joins. > > Do you ever use the Database Engine Tuning Advisor? Does it collapse when > it sees your database? I used it recently and it suggested I create a > bunch of compound indexes. It gave me some performance increases. > > Mark > > > On 19 June 2012 21:34, jwcolby wrote: > >> I have a pair of tables. Both tables have a clustered index on an integer >> PK. TableA the PK is an autonumber. TableB the PK is the PK from TableA, >> i.e. it is 1 to 1. >> >> TableA is updated monthly, TableA and TableB both get records added >> occasionally. I just added about 180 million records to both tables. I do >> occasionally delete records from both as the data ages. >> >> For providing counts to my client I need to join the two tables on the PK, >> then pull a single field from TableA and a handful of fields from TableB. >> From there I will be doing count / group by kind of things. >> >> I created a view to pull all of the fields used in these counts. I >> thought I would create an index on the view. >> >> Is this a good idea? I have never indexed a view but I know it is >> possible. >> >> -- >> John W. Colby >> Colby Consulting >> >> Reality is what refuses to go away >> when you do not believe in it >> >> >> ______________________________**_________________ >> dba-SQLServer mailing list >> dba-SQLServer@**databaseadvisors.com >> http://databaseadvisors.com/**mailman/listinfo/dba-sqlserver >> http://www.databaseadvisors.**com >> >> > _______________________________________________ > dba-SQLServer mailing list > dba-SQLServer at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/dba-sqlserver > http://www.databaseadvisors.com > > From jwcolby at colbyconsulting.com Wed Jun 20 11:10:56 2012 From: jwcolby at colbyconsulting.com (jwcolby) Date: Wed, 20 Jun 2012 12:10:56 -0400 Subject: [dba-SQLServer] Index on view In-Reply-To: <4FE1C9CE.1090607@colbyconsulting.com> References: <4FE0E26D.8070306@colbyconsulting.com> <4FE1C9CE.1090607@colbyconsulting.com> Message-ID: <4FE1F610.5080105@colbyconsulting.com> One thing I have discovered, if you make changes to the query it knocks off the indexes. I added a state table joined to the state field in one of the tables in the view. I did not actually pull any data out of that table, just did an inner join to force only records in the state table to be used in the view (we don't use fleet post office, guam etc). When I tried to save the query with this additional table joined in it came back with a "timeout" kind of error message. However when I looked at the query it did have the new table joined in, but the indexes I had just created were missing. John W. Colby Colby Consulting Reality is what refuses to go away when you do not believe in it On 6/20/2012 9:02 AM, jwcolby wrote: > I am creating a pair of indexes now. I apparently have to create a clustered index and then > whatever other indexes I need. Why I am not sure but it refuses to create non-clustered indexes > until the clustered index exists. > > I also use compression everywhere. Even though I have 64 gigs of memory, compression allows much > more to fit into memory, and with 16 cores available, there are spare cores available to perform the > decompression as data is used. > > > I try never to join on views, I have always found that to be terribly slow. I prefer to write > one long SQL statement with nest joins. > > According to my reading, when this happens, SQL Server simply extracts all of the view metadata and > builds up the equivalent of your "one long sql statement with nested joins". Of course there is the > time required to analyze and perform that sql statement build so it would be somewhat slower on the > front end. One would expect the actual query execution to be the same speed. > > > John W. Colby > Colby Consulting > > Reality is what refuses to go away > when you do not believe in it > > > On 6/20/2012 3:56 AM, Mark Breen wrote: >> Hello John, >> >> I have no idea, but I would like to hear what your experiences are. >> >> I accidentally created an index on a view recently and I cannot report on >> performance, but I notice that it takes up space in the database. >> >> I try never to join on views, I have always found that to be terribly slow. >> I prefer to write one long SQL statement with nest joins. >> >> Do you ever use the Database Engine Tuning Advisor? Does it collapse when >> it sees your database? I used it recently and it suggested I create a >> bunch of compound indexes. It gave me some performance increases. >> >> Mark >> >> >> On 19 June 2012 21:34, jwcolby wrote: >> >>> I have a pair of tables. Both tables have a clustered index on an integer >>> PK. TableA the PK is an autonumber. TableB the PK is the PK from TableA, >>> i.e. it is 1 to 1. >>> >>> TableA is updated monthly, TableA and TableB both get records added >>> occasionally. I just added about 180 million records to both tables. I do >>> occasionally delete records from both as the data ages. >>> >>> For providing counts to my client I need to join the two tables on the PK, >>> then pull a single field from TableA and a handful of fields from TableB. >>> From there I will be doing count / group by kind of things. >>> >>> I created a view to pull all of the fields used in these counts. I >>> thought I would create an index on the view. >>> >>> Is this a good idea? I have never indexed a view but I know it is >>> possible. >>> >>> -- >>> John W. Colby >>> Colby Consulting >>> >>> Reality is what refuses to go away >>> when you do not believe in it >>> >>> >>> ______________________________**_________________ >>> dba-SQLServer mailing list >>> dba-SQLServer@**databaseadvisors.com >>> http://databaseadvisors.com/**mailman/listinfo/dba-sqlserver >>> >>> http://www.databaseadvisors.**com >>> >>> >> _______________________________________________ >> dba-SQLServer mailing list >> dba-SQLServer at databaseadvisors.com >> http://databaseadvisors.com/mailman/listinfo/dba-sqlserver >> http://www.databaseadvisors.com >> >> > > > _______________________________________________ > dba-SQLServer mailing list > dba-SQLServer at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/dba-sqlserver > http://www.databaseadvisors.com > > From marklbreen at gmail.com Wed Jun 20 15:50:36 2012 From: marklbreen at gmail.com (Mark Breen) Date: Wed, 20 Jun 2012 21:50:36 +0100 Subject: [dba-SQLServer] Index on view In-Reply-To: <4FE1C9CE.1090607@colbyconsulting.com> References: <4FE0E26D.8070306@colbyconsulting.com> <4FE1C9CE.1090607@colbyconsulting.com> Message-ID: Hi John, > I try never to join on views, I have always found that to be terribly slow. I prefer to write one long SQL statement with nest joins. According to my reading, when this happens, SQL Server simply extracts all of the view metadata and builds up the equivalent of your "one long sql statement with nested joins". Of course there is the time required to analyze and perform that sql statement build so it would be somewhat slower on the front end. One would expect the actual query execution to be the same speed. really, that is good to hear, I always struggled with linking views, as you say, maybe it was just because it was a lot of SQL anyway. Thanks Mark From fuller.artful at gmail.com Fri Jun 22 16:18:56 2012 From: fuller.artful at gmail.com (Arthur Fuller) Date: Fri, 22 Jun 2012 17:18:56 -0400 Subject: [dba-SQLServer] Access Denied when trying to attach a database Message-ID: I think I've asked this before, but if so I've forgotten the answer. I'm trying to attach a sample database from the book "SQL Server 2008 MDX Step by Step", and I'm getting this error. Anybody know the way around this problem? TIA, -- Arthur Cell: 647.710.1314 Prediction is difficult, especially of the future. -- Niels Bohr