Comments
Sort by recent activity
Certainly is. I do it all the time, especially on the cluster.
I take it by your reply, Peter, that besides this simple "manual install", there are no issues to work through and that I can very easily restore a SS2005EE set of databases onto a SS2012RC0 box, upgrade the compatibility level and test? (I really hope the answer is "Yes" 8) )
Thanks for taking the time to respond to my original post. / comments
Certainly is. I do it all the time, especially on the cluster.
I take it by your reply, Peter, that besides this simple "manual install", there are no issues to work through and that I can very ea...
I, too, am astounded at the rapid appearance of "Unknown"!
I added an SP this morning and within three hours "I" became "Unknown". There's NOBODY ELSE on the server - I'm the ONLY DB Developer... There are a few background jobs acquiring fresh data from Production but they're only actually creating rows on 5 of 60 executions per hour.
I wouldn't expect MY default trace file to roll-over in just 3 hours!
In my case, as I'm "it", I know whodunnit, but it is still a BIG BUG crying out for a rapid fix (IMO). When, please? / comments
I, too, am astounded at the rapid appearance of "Unknown"!
I added an SP this morning and within three hours "I" became "Unknown". There's NOBODY ELSE on the server - I'm the ONLY DB Developer... ...
As this is on the Production cluster, running a 24x7 app, we'll wait until the regular monthly maintenance failover.
Thanks for opening the case. / comments
As this is on the Production cluster, running a 24x7 app, we'll wait until the regular monthly maintenance failover.
Thanks for opening the case.
We had the JSON length issue in our Production .Net application and simply changed the config to get around it. No such ability with SQL Monitor? / comments
We had the JSON length issue in our Production .Net application and simply changed the config to get around it. No such ability with SQL Monitor?
The process, in simple terms, all under the dbo schema, was:
DROP Indexed View t_meter_clean, which had a PK of pk_t_meter_clean.
DROP the table on which the View was built (only 1 table in the view's SELECT).
CREATE table t_meter_clean.
ADD PK constraint pk_t_meter_clean.
Add TRIGGER to table t_meter_clean.
COMMIT to SSC.
The result:
View t_meter_clean persisted in SVN.
The table was added to SVN.
The TRIGGER was added to the VIEW.
Any attempt to Commit AFTER the COMMIT above failed due to the presence of the pk_t_meter_clean PK on the VIEW.
Hope this helps. / comments
The process, in simple terms, all under the dbo schema, was:
DROP Indexed View t_meter_clean, which had a PK of pk_t_meter_clean.
DROP the table on which the View was built (only 1 table in the vi...
James, your directives worked fine:
So, I can get it working simply by deleting the file in the "Views" folder using Tortoise's repo browser then unlinking and relinking. Assuming that the view is no longer required (which sounds like the case based on your email) it should be the quickest way to get things running.
DB unlinked and relinked and I can now Commit again.
Perhaps it would be valuable to examine how the trigger update was assigned to the wrong object on Commit...? Maybe the object type qualification was missed in the logic...? / comments
James, your directives worked fine:
So, I can get it working simply by deleting the file in the "Views" folder using Tortoise's repo browser then unlinking and relinking. Assuming that the view i...
DB is actually small in schema but relatively large in data, so I'll gladly zip the SVN folder. Where should I send it? / comments
DB is actually small in schema but relatively large in data, so I'll gladly zip the SVN folder. Where should I send it?
Eamiled to the support @ address with this thread URL as the subject. / comments
Eamiled to the support @ address with this thread URL as the subject.
I looked down the views\ folder and at the .svn content. The trigger on the TABLE has been assigned to the defunct VIEW, which never had a trigger as it was a materialized view.
Wires appear crossed during the update where the View deletion was not completed and the object removed from candidature for dependant objects... / comments
I looked down the views\ folder and at the .svn content. The trigger on the TABLE has been assigned to the defunct VIEW, which never had a trigger as it was a materialized view.
Wires appear cross...
Cropped up, yes. What to do with the info - do tell...
U:\EPS_Deployment\xChangePoint\src\Database\SSC\xcp_trans>findstr /S /C:"pk_t_meter_clean" *.*
Tables\.svn\text-base\dbo.t_meter_clean.sql.svn-base:ALTER TABLE [dbo].[t_meter_clean] ADD CONSTRAINT [pk_t_meter_clean] PRIMARY KEY CLUSTERED ([location_variable_id], [t_stamp], [input_id], [t_stamp_utc_delta]) ON [PRIMARY]
Tables\dbo.t_meter_clean.sql:ALTER TABLE [dbo].[t_meter_clean] ADD CONSTRAINT [pk_t_meter_clean] PRIMARY KEY CLUSTERED ([location_variable_id], [t_stamp], [input_id], [t_stamp_utc_delta]) ON [PRIMARY]
Views\.svn\text-base\dbo.t_meter_clean.sql.svn-base:CONSTRAINT [pk_t_meter_clean] PRIMARY KEY CLUSTERED ([location_variable_id], [t_stamp], [input_id], [t_stamp_utc_delta]) ON [PRIMARY]
Views\dbo.t_meter_clean.sql:CONSTRAINT [pk_t_meter_clean] PRIMARY KEY CLUSTERED ([location_variable_id], [t_stamp], [input_id], [t_stamp_utc_delta]) ON [PRIMARY]
The VIEW no longer exists - I nuked it in the re-architecture. The fact that it's still there is a reflection of the history of the database and is correct. However, it's existence in the annals of history prevents me from reflecting the current DB schema correctly, as reflected in the Tables\ rows.
How does one clean this up? / comments
Cropped up, yes. What to do with the info - do tell...
U:\EPS_Deployment\xChangePoint\src\Database\SSC\xcp_trans>findstr /S /C:"pk_t_meter_clean" *.*
Tables\.svn\text-base\dbo.t_meter_clean.sql...