Monday, March 19, 2012
error 1203,severity 20, state 1
im getting the below erro
error 1203,severity 20, state
i was running my interest calculation procedures..its a abanking site..and it updates around 1-2 million records.
profiler is showing this error as exception..but when i saw sysprocess ..that spid is runnable and i can see cpu and io values updated.
wot can be the source of error.
thanks
sanjayHi.
On BOOKS ONLINE:
Error 1203
Severity Level 20
Message Text
Process ID %d attempting to unlock unowned resource %.*ls.
Explanation
This error occurs when Microsoft=AE SQL ServerT is engaged in some activity other than normal post-processing cleanup and it finds that a particular page it is attempting to unlock is already unlocked. The underlying cause for this error may be related to structural problems within the affected database. SQL Server manages the acquisition and release of pages to maintain concurrency control in the multi-user environment. This mechanism is maintained through the use of various internal lock structures that identify the page and the type of lock present. Locks are acquired for processing of affected pages and released when the processing is completed.
Action
Execute DBCC CHECKDB against the database in which the object belongs. If DBCC CHECKDB reports no errors, attempt to reestablish the connection and execute the command
>--Original Message--
>hi,
> im getting the below error
> error 1203,severity 20, state 1
>i was running my interest calculation procedures..its a abanking site..and it updates around 1-2 million records..
>profiler is showing this error as exception..but when i saw sysprocess ..that spid is runnable and i can see cpu and io values updated..
>wot can be the source of error..
>thanks >sanjay
>.
>|||thnks for reply..
i tried but same error..
Sunday, March 11, 2012
error 1069: The service did not start due to logon problems
The local sql server that was working fine earlier does not start now. I have already created tables and accessed them using stored procedures.
I get an error 1069: The service did not start due to logon problems. I have only changed my domain password. I do not remember what authentication I chose for log on.
Any suggestions would be helpful.
Thanks
try this article:
http://support.microsoft.com/default.aspx?scid=kb;EN-US;Q282254
error 1069: The service did not start due to logon problems
The local sql server that was working fine earlier does not start now. I have already created tables and accessed them using stored procedures.
I get an error 1069: The service did not start due to logon problems. I have only changed my domain password. I do not remember what authentication I chose for log on.
Any suggestions would be helpful.
Thanks
try this article:
http://support.microsoft.com/default.aspx?scid=kb;EN-US;Q282254
Sunday, February 26, 2012
Error : Cannot specify an index or locking hint for a remote data source
being leaving the database in sql 7 compatabiliy mode.
Some of the stored procedures reference the tables on a
linked server. The linked server is running sql 2000 and
the database is sql 2000.
When I run the following command
select * from linked_server.database.dbo.tablename (nolock)
I receive the following error
Cannot specify an index or locking hint for a remote data
source.
If I remove the () around nolock the statement runs.
The question(s) I have
1. Did I set something up wrong?
2. Without the () is the nolock still performing the same
function?
3. Assumining I did not error on the configuration, Why do
I receive this error now, and not before?
4. Any ideas to fix the problem without removing the ()?
Thanks in advance for any suggestions/ideas.
John WilliamsWithout the brackets around nolock, the SQL query engine is assigning the
word 'nolock' as an alias to your table in the select statement (i.e.
equivalent to 'as [nolock]').
R
"John Williams" <anonymous@.discussions.microsoft.com> wrote in message
news:27f3501c4636b$941fa990$a301280a@.phx.gbl...
> We are migrating from sql 7 to sql 2000 and for the time
> being leaving the database in sql 7 compatabiliy mode.
> Some of the stored procedures reference the tables on a
> linked server. The linked server is running sql 2000 and
> the database is sql 2000.
> When I run the following command
> select * from linked_server.database.dbo.tablename (nolock)
> I receive the following error
> Cannot specify an index or locking hint for a remote data
> source.
> If I remove the () around nolock the statement runs.
> The question(s) I have
> 1. Did I set something up wrong?
> 2. Without the () is the nolock still performing the same
> function?
> 3. Assumining I did not error on the configuration, Why do
> I receive this error now, and not before?
> 4. Any ideas to fix the problem without removing the ()?
> Thanks in advance for any suggestions/ideas.
> John Williams|||Can you not create a stored procedure on the remote data source that
specifies the hint?
--
http://www.aspfaq.com/
(Reverse address to reply.)
"John Williams" <anonymous@.discussions.microsoft.com> wrote in message
news:27f3501c4636b$941fa990$a301280a@.phx.gbl...
> We are migrating from sql 7 to sql 2000 and for the time
> being leaving the database in sql 7 compatabiliy mode.
> Some of the stored procedures reference the tables on a
> linked server. The linked server is running sql 2000 and
> the database is sql 2000.
> When I run the following command
> select * from linked_server.database.dbo.tablename (nolock)
> I receive the following error
> Cannot specify an index or locking hint for a remote data
> source.
> If I remove the () around nolock the statement runs.
> The question(s) I have
> 1. Did I set something up wrong?
> 2. Without the () is the nolock still performing the same
> function?
> 3. Assumining I did not error on the configuration, Why do
> I receive this error now, and not before?
> 4. Any ideas to fix the problem without removing the ()?
> Thanks in advance for any suggestions/ideas.
> John Williams|||I am not sure if I understand what you are asking? Are you
suggesting that the stored procedure we run on the server
that has the syntax.
Select & from linkerserver.database.dbo.table1 and instead
run a stored procedure on the linked server that
accomplishes the same thing? I can look into this as an
option.
Thanks...
>--Original Message--
>Can you not create a stored procedure on the remote data
source that
>specifies the hint?
>--
>http://www.aspfaq.com/
>(Reverse address to reply.)
>
>
>"John Williams" <anonymous@.discussions.microsoft.com>
wrote in message
>news:27f3501c4636b$941fa990$a301280a@.phx.gbl...
>> We are migrating from sql 7 to sql 2000 and for the time
>> being leaving the database in sql 7 compatabiliy mode.
>> Some of the stored procedures reference the tables on a
>> linked server. The linked server is running sql 2000 and
>> the database is sql 2000.
>> When I run the following command
>> select * from linked_server.database.dbo.tablename
(nolock)
>> I receive the following error
>> Cannot specify an index or locking hint for a remote
data
>> source.
>> If I remove the () around nolock the statement runs.
>> The question(s) I have
>> 1. Did I set something up wrong?
>> 2. Without the () is the nolock still performing the
same
>> function?
>> 3. Assumining I did not error on the configuration, Why
do
>> I receive this error now, and not before?
>> 4. Any ideas to fix the problem without removing the ()?
>> Thanks in advance for any suggestions/ideas.
>> John Williams
>
>.
>|||Thanks,
That an excellent point, so I am going to get unwanted
results by removing the (), I am concerned about locking
though, do you know since I cannot specify the nolock
hint, am I getting the benefit of (nolock) somehow?
>--Original Message--
>Without the brackets around nolock, the SQL query engine
is assigning the
>word 'nolock' as an alias to your table in the select
statement (i.e.
>equivalent to 'as [nolock]').
>R
>"John Williams" <anonymous@.discussions.microsoft.com>
wrote in message
>news:27f3501c4636b$941fa990$a301280a@.phx.gbl...
>> We are migrating from sql 7 to sql 2000 and for the time
>> being leaving the database in sql 7 compatabiliy mode.
>> Some of the stored procedures reference the tables on a
>> linked server. The linked server is running sql 2000 and
>> the database is sql 2000.
>> When I run the following command
>> select * from linked_server.database.dbo.tablename
(nolock)
>> I receive the following error
>> Cannot specify an index or locking hint for a remote
data
>> source.
>> If I remove the () around nolock the statement runs.
>> The question(s) I have
>> 1. Did I set something up wrong?
>> 2. Without the () is the nolock still performing the
same
>> function?
>> 3. Assumining I did not error on the configuration, Why
do
>> I receive this error now, and not before?
>> 4. Any ideas to fix the problem without removing the ()?
>> Thanks in advance for any suggestions/ideas.
>> John Williams
>
>.
>|||Yes, I think you will find that if you create a stored procedure on the
remote server, instead of running an ad hoc query locally, you will have
more freedom over transactions within the proc, locking hints, etc. You
should always be using stored procs as opposed to ad hoc statements
anyway...
--
http://www.aspfaq.com/
(Reverse address to reply.)
<anonymous@.discussions.microsoft.com> wrote in message
news:274bb01c46371$b02b52a0$a501280a@.phx.gbl...
> I am not sure if I understand what you are asking? Are you
> suggesting that the stored procedure we run on the server
> that has the syntax.
> Select & from linkerserver.database.dbo.table1 and instead
> run a stored procedure on the linked server that
> accomplishes the same thing? I can look into this as an
> option.
> Thanks...
>
> >--Original Message--
> >Can you not create a stored procedure on the remote data
> source that
> >specifies the hint?
> >
> >--
> >http://www.aspfaq.com/
> >(Reverse address to reply.)
> >
> >
> >
> >
> >"John Williams" <anonymous@.discussions.microsoft.com>
> wrote in message
> >news:27f3501c4636b$941fa990$a301280a@.phx.gbl...
> >> We are migrating from sql 7 to sql 2000 and for the time
> >> being leaving the database in sql 7 compatabiliy mode.
> >> Some of the stored procedures reference the tables on a
> >> linked server. The linked server is running sql 2000 and
> >> the database is sql 2000.
> >>
> >> When I run the following command
> >> select * from linked_server.database.dbo.tablename
> (nolock)
> >>
> >> I receive the following error
> >> Cannot specify an index or locking hint for a remote
> data
> >> source.
> >>
> >> If I remove the () around nolock the statement runs.
> >>
> >> The question(s) I have
> >>
> >> 1. Did I set something up wrong?
> >> 2. Without the () is the nolock still performing the
> same
> >> function?
> >> 3. Assumining I did not error on the configuration, Why
> do
> >> I receive this error now, and not before?
> >> 4. Any ideas to fix the problem without removing the ()?
> >>
> >> Thanks in advance for any suggestions/ideas.
> >>
> >> John Williams
> >
> >
> >.
> >
Friday, February 17, 2012
Error
CREATE PROCEDURE [InsertGCTerms]
AS
INSERT INTO [CommissionEmployee_Exclusionsdb].[dbo].[GCEmployeeTerms]([TM #],[FirstName],[LastName],[SocialSecurityNumber],[DateHired],[DepartmentName],[Title])
SELECT a.[TM#], a.LASTNAME, a.FIRSTNAME, a.[SSN#], a.HIREDATE,
a.[DEPT#], a.JOBTITLE FROM GOVEMPLYS AS a
WHERE a.STATUS = 'TERMINATED'
RETURN
GOCan you coach us just a bit on what to do if an error occurs? You can always use the "panic, scream, and shout" approach, but I generally prefer something just a bit more elegant!
-PatP|||I was trying to use the @.@. Error system function|||It appears that I'm not making my question very clear. Let's go for the ever loving example, maybe that will help!CREATE PROCEDURE [InsertGCTerms]
AS
INSERT INTO [CommissionEmployee_Exclusionsdb].[dbo].[GCEmployeeTerms] (
[TM #], [FirstName], [LastName]
, [SocialSecurityNumber], [DateHired], [DepartmentName]
, [Title] ) SELECT
a.[TM#], a.FIRSTNAME, a.LASTNAME
, a.[SSN#], a.HIREDATE , a.[DEPT#]
, a.JOBTITLE
FROM GOVEMPLYS AS a
WHERE a.STATUS = 'TERMINATED'
IF 0 <> @.@.error RAISERROR ('Scream and shout, run and panic!')
RETURN
GO-PatP|||Ok sorry I see your point..LOL that was funny, need a good laugh in the morning. sorry I didnt make myself clear. But basically pat you already answered my question and now I see where I went wrong. I am so glad I ordered the http://search.barnesandnoble.com/booksearch/isbnInquiry.asp?userid=bsq1M1M1GT&isbn=1565924010&itm=1 Book this will help me out tremendously, I need a book all about programming in sql.|||I would look at
Ken Hendersons Book (http://search.barnesandnoble.com/booksearch/isbninquiry.asp?userid=6F22YrtiAX&pwb=1&ean=9780201615760)
Also...did someone say error handling?
http://weblogs.sqlteam.com/brettk/archive/2004/05/25/1378.aspx|||Yes I originally ordered that book but apparently it was out of stock or something, they refunded my money back got the message via email. Yes I was inquiring about Error Handling|||Amazon out of stock?
I doubt it
And did you look at my link?
Follow the steps to save the tql file to your machine...|||ok Brett I ordered the book, those two should help me out tremendously. Thank you :)|||Great...but did you look at the error handling tql file in my blog?|||Yes Brett I am looking that over now thank yoiu
Wednesday, February 15, 2012
Erroneously deleted stored procedures
able to do point-in-time restore to get back your deleted
procedures (if the log backup chain has not been broken):
1. Do a BACKUP LOG first
2. Do (using pubs as example)
restore database pubs from disk='...'
rstore log ... -- if any
restore log pubs from disk='...' -- the last log backup
with recovery, stopat = '20031010 17:59:59'
The STOPAT time should be before the time the procedures
were deleted.
Linchi
>--Original Message--
>I have a teammate that, in an excess of zeal, managed to
delete a majority of stored procedures on a production
database, causing numerous jobs to fail. Additionally,
there were no receint backups of this database taken, but
the transaction log is still in place and has not been
truncated. Is there any way to recover these stored
procedures that I am unaware of?
>.
>
Erratic Performance of SQL Server
Hello,
We have a complex system with many stored procedures, the same procedures run every day at about the same time. We are noticing severe fluctuations in performance. One day a procedure will take 150 minutes, the next day 250 minutes, the next day 100 minutes. A graph of the performance looks like a voice graph or a lie detector for a criminal. We are using SQL Server 2000 on an Itanium. Any suggestions or hints about how to stablize? This is happening for all of our procedures that run 24 hours a day.
Hi.
Are you running with SQL Server 2000 service pack 4 (for build 2039) and the last 2000 cumulative hotfix package (for build 2187)?
Regards,
Gary.
|||Stored procedure performance is always going to be directly relative to the load on the server, the number of rows being processed, the nature of the queries, i.e. read only versus updates and, in particular, on the performance of the I/O devices which can certainly vary if your stored procedures are competing against other processes trying to access the same data.What is the stored procedure doing and what kind of data volumes are we talking about, i.e. a thousand rows, 10 million rows? Are there any cursors? Are there any other applications competing for the same data, i.e. an OLTP system?
|||
You might want to take the following steps:
1. Check the DBCC SHOW_STATISTICS and rowmodctr values (under the sysindexes table -- The rowmodctr value should be as close to ZERO as possible) and find out if the statistics for the database and the tables involved are out of date. If yes, please update the statistics with a full scan or 100% sampling rate.
2. Make sure that you are not running into a parameter sniffing issue. Please refer the following article for more details:
http://www.microsoft.com/technet/prodtechnol/sql/2005/recomp.mspx
http://msdn2.microsoft.com/en-us/library/ms190439.aspx
Sporadic bursts in SP performance which leads to inconsistent duration for a stored procedure would be due to recompilation of the SP with a bad input parameter which generates a bad plan.
Also, try and see if recompiling the stored procedure at that particular time helps.
|||You need to itemize your durations. If you run Profiler, you will see real execution costs, such as amount of CPU and number of reads/writes. Are these values wildly different from day to day? Note that different durations may be caused by:- locking, when you procedure spends significant time in lock waiting state;
- network delays. Your procedure may be waiting for the client to receive the result sets.
For instance, you can run one and the same query twice and get the same CPU, the same reads, but very different duration, because one time there were no exclusive locks to wait for, and the other time the procedure spent most of the time in lock ewaiting state. Another example is when you invoke a query from SSMS, and most of the duration is spent by SSMS drawing a grid. If you switch to text mode and rerun the query, you may get a shorter duration.|||
Thanks for your replies, I'll look at these in more detail, but I want to provide some additional information.
We are running SQL Server 2000, Enterprise edition, 64-bit, version 8.00.2039 SP4. Our server is not shared by any other application, but we have two instances with concurrent processing. The two instances use separate databases, but each instance has 3 job queues that can run procesing tasks simultaneously. Locking could be an issue on one instance, but not on the other instance. We are observing the same erratic processing times on both instances. Our SQL server uses a SAN, which is used by other applications, but the processing performed by the other applications is very light. We have several different procedures, most are not parameterized. Some of our longest running stored procedures perform a fairly simple SELECT INTO with joins on master data tables -- but these procedures are the most erratic with regard to different processing times. The data volumes for these procedures is up to about 20 million records. Locking is not an issue in these procedures. Since all of our procedures seem to be erratic, I'm wondering if there might be a problem with the SQL server optimizer in our configuration.
|||Have you monitored your TempDB's? If they're too small, it will have to keep extending which is a serious drag on performance. If your stored procedures are doing a lot of sorts, group by's, and are using a lot of temp tables this might add further credence to the TempDB issue. Since you're using SELECT INTO the operations are unlogged so I doubt that's your problem. You also might monitor your QIO's on your SAN devices to see if there is a lot of contention, particularly on the device with TempDB on it. (If at all possible you might move the TempDB's to their own devices.) You might also consider creating one TempDB file for each processor if you haven't already and turning on Traceflag 1118.Just some thoughts. Hope it helps.
Erratic Performance of SQL Server
Hello,
We have a complex system with many stored procedures, the same procedures run every day at about the same time. We are noticing severe fluctuations in performance. One day a procedure will take 150 minutes, the next day 250 minutes, the next day 100 minutes. A graph of the performance looks like a voice graph or a lie detector for a criminal. We are using SQL Server 2000 on an Itanium. Any suggestions or hints about how to stablize? This is happening for all of our procedures that run 24 hours a day.
Hi.
Are you running with SQL Server 2000 service pack 4 (for build 2039) and the last 2000 cumulative hotfix package (for build 2187)?
Regards,
Gary.
|||Stored procedure performance is always going to be directly relative to the load on the server, the number of rows being processed, the nature of the queries, i.e. read only versus updates and, in particular, on the performance of the I/O devices which can certainly vary if your stored procedures are competing against other processes trying to access the same data.What is the stored procedure doing and what kind of data volumes are we talking about, i.e. a thousand rows, 10 million rows? Are there any cursors? Are there any other applications competing for the same data, i.e. an OLTP system?
|||
You might want to take the following steps:
1. Check the DBCC SHOW_STATISTICS and rowmodctr values (under the sysindexes table -- The rowmodctr value should be as close to ZERO as possible) and find out if the statistics for the database and the tables involved are out of date. If yes, please update the statistics with a full scan or 100% sampling rate.
2. Make sure that you are not running into a parameter sniffing issue. Please refer the following article for more details:
http://www.microsoft.com/technet/prodtechnol/sql/2005/recomp.mspx
http://msdn2.microsoft.com/en-us/library/ms190439.aspx
Sporadic bursts in SP performance which leads to inconsistent duration for a stored procedure would be due to recompilation of the SP with a bad input parameter which generates a bad plan.
Also, try and see if recompiling the stored procedure at that particular time helps.
|||You need to itemize your durations. If you run Profiler, you will see real execution costs, such as amount of CPU and number of reads/writes. Are these values wildly different from day to day? Note that different durations may be caused by:- locking, when you procedure spends significant time in lock waiting state;
- network delays. Your procedure may be waiting for the client to receive the result sets.
For instance, you can run one and the same query twice and get the same CPU, the same reads, but very different duration, because one time there were no exclusive locks to wait for, and the other time the procedure spent most of the time in lock ewaiting state. Another example is when you invoke a query from SSMS, and most of the duration is spent by SSMS drawing a grid. If you switch to text mode and rerun the query, you may get a shorter duration.|||
Thanks for your replies, I'll look at these in more detail, but I want to provide some additional information.
We are running SQL Server 2000, Enterprise edition, 64-bit, version 8.00.2039 SP4. Our server is not shared by any other application, but we have two instances with concurrent processing. The two instances use separate databases, but each instance has 3 job queues that can run procesing tasks simultaneously. Locking could be an issue on one instance, but not on the other instance. We are observing the same erratic processing times on both instances. Our SQL server uses a SAN, which is used by other applications, but the processing performed by the other applications is very light. We have several different procedures, most are not parameterized. Some of our longest running stored procedures perform a fairly simple SELECT INTO with joins on master data tables -- but these procedures are the most erratic with regard to different processing times. The data volumes for these procedures is up to about 20 million records. Locking is not an issue in these procedures. Since all of our procedures seem to be erratic, I'm wondering if there might be a problem with the SQL server optimizer in our configuration.
|||Have you monitored your TempDB's? If they're too small, it will have to keep extending which is a serious drag on performance. If your stored procedures are doing a lot of sorts, group by's, and are using a lot of temp tables this might add further credence to the TempDB issue. Since you're using SELECT INTO the operations are unlogged so I doubt that's your problem. You also might monitor your QIO's on your SAN devices to see if there is a lot of contention, particularly on the device with TempDB on it. (If at all possible you might move the TempDB's to their own devices.) You might also consider creating one TempDB file for each processor if you haven't already and turning on Traceflag 1118.Just some thoughts. Hope it helps.
Erratic Performance of SQL Server
Hello,
We have a complex system with many stored procedures, the same procedures run every day at about the same time. We are noticing severe fluctuations in performance. One day a procedure will take 150 minutes, the next day 250 minutes, the next day 100 minutes. A graph of the performance looks like a voice graph or a lie detector for a criminal. We are using SQL Server 2000 on an Itanium. Any suggestions or hints about how to stablize? This is happening for all of our procedures that run 24 hours a day.
Hi.
Are you running with SQL Server 2000 service pack 4 (for build 2039) and the last 2000 cumulative hotfix package (for build 2187)?
Regards,
Gary.
|||Stored procedure performance is always going to be directly relative to the load on the server, the number of rows being processed, the nature of the queries, i.e. read only versus updates and, in particular, on the performance of the I/O devices which can certainly vary if your stored procedures are competing against other processes trying to access the same data.What is the stored procedure doing and what kind of data volumes are we talking about, i.e. a thousand rows, 10 million rows? Are there any cursors? Are there any other applications competing for the same data, i.e. an OLTP system?
|||
You might want to take the following steps:
1. Check the DBCC SHOW_STATISTICS and rowmodctr values (under the sysindexes table -- The rowmodctr value should be as close to ZERO as possible) and find out if the statistics for the database and the tables involved are out of date. If yes, please update the statistics with a full scan or 100% sampling rate.
2. Make sure that you are not running into a parameter sniffing issue. Please refer the following article for more details:
http://www.microsoft.com/technet/prodtechnol/sql/2005/recomp.mspx
http://msdn2.microsoft.com/en-us/library/ms190439.aspx
Sporadic bursts in SP performance which leads to inconsistent duration for a stored procedure would be due to recompilation of the SP with a bad input parameter which generates a bad plan.
Also, try and see if recompiling the stored procedure at that particular time helps.
|||You need to itemize your durations. If you run Profiler, you will see real execution costs, such as amount of CPU and number of reads/writes. Are these values wildly different from day to day? Note that different durations may be caused by:- locking, when you procedure spends significant time in lock waiting state;
- network delays. Your procedure may be waiting for the client to receive the result sets.
For instance, you can run one and the same query twice and get the same CPU, the same reads, but very different duration, because one time there were no exclusive locks to wait for, and the other time the procedure spent most of the time in lock ewaiting state. Another example is when you invoke a query from SSMS, and most of the duration is spent by SSMS drawing a grid. If you switch to text mode and rerun the query, you may get a shorter duration.|||
Thanks for your replies, I'll look at these in more detail, but I want to provide some additional information.
We are running SQL Server 2000, Enterprise edition, 64-bit, version 8.00.2039 SP4. Our server is not shared by any other application, but we have two instances with concurrent processing. The two instances use separate databases, but each instance has 3 job queues that can run procesing tasks simultaneously. Locking could be an issue on one instance, but not on the other instance. We are observing the same erratic processing times on both instances. Our SQL server uses a SAN, which is used by other applications, but the processing performed by the other applications is very light. We have several different procedures, most are not parameterized. Some of our longest running stored procedures perform a fairly simple SELECT INTO with joins on master data tables -- but these procedures are the most erratic with regard to different processing times. The data volumes for these procedures is up to about 20 million records. Locking is not an issue in these procedures. Since all of our procedures seem to be erratic, I'm wondering if there might be a problem with the SQL server optimizer in our configuration.
|||Have you monitored your TempDB's? If they're too small, it will have to keep extending which is a serious drag on performance. If your stored procedures are doing a lot of sorts, group by's, and are using a lot of temp tables this might add further credence to the TempDB issue. Since you're using SELECT INTO the operations are unlogged so I doubt that's your problem. You also might monitor your QIO's on your SAN devices to see if there is a lot of contention, particularly on the device with TempDB on it. (If at all possible you might move the TempDB's to their own devices.) You might also consider creating one TempDB file for each processor if you haven't already and turning on Traceflag 1118.Just some thoughts. Hope it helps.