Comments
Sort by recent activity
Bart, I'm afraid not.
First of all, you asummed incorrectly, But hey, how could you know? I didn't tell you. The insert script is one line per insert, I formatted so it would look OK in the thread. I increased the number of lines as suggested anyway but no difference. The SECONDAY file group may be a factor, let me try it in a different DB, but put the table in the PRIMARY file group...
Hmm. Seemed to help with the query as posted, but when I loaded the 11 line (1 line to each insert) script, I see the same behaviour.
I do appreciate your efforts in responding to this btw, and your honesty [image]
Dave / comments
Bart, I'm afraid not.
First of all, you asummed incorrectly, But hey, how could you know? I didn't tell you. The insert script is one line per insert, I formatted so it would look OK in the thread...
Bart Read wrote:
Can you open the Options dialog, and then to the "Variable and Parameters" screen on the "Listed Candidates" tab, and then make sure that "Search a fixed number of lines..." is selected please?
I did, and it is selected and is set to 50 lines. The script in question contains no parameters or variables btw, it's a straight insert into an admittedly very wide table.
HTH
Dave / comments
Bart Read wrote:
Can you open the Options dialog, and then to the "Variable and Parameters" screen on the "Listed Candidates" tab, and then make sure that "Search a fixed number of lines..." i...
Hello Bart
I'm afraid it's definitely not caching. I can open a connection to the db, watch the window appear , then disappear, then load the script and then watch my CPU spike up to 99% for up to 3 minutes. When I get control back, if I click anywhere else in the window, it appears to re-parse and takes an age to come back again. Note, this is just clicking elsewhere in the window, not typing anything.
I can post the table DDL and the DML script if you think it will help you solve this
Dave J / comments
Hello Bart
I'm afraid it's definitely not caching. I can open a connection to the db, watch the window appear , then disappear, then load the script and then watch my CPU spike up to 99% for up to...
I have upgraded to version 3.5 but I still see CPU spiking up to 98% (isqlw.exe process) when I load an insert script. The script is too wide to post here, though I can if you like, but it is a sraight
INSERT INTO [table_name] (column list) values(1,1,...)
It contains 11 Insert statements into a table with 65 columns.
This is enough to make me turn it off.
Dave J / comments
I have upgraded to version 3.5 but I still see CPU spiking up to 98% (isqlw.exe process) when I load an insert script. The script is too wide to post here, though I can if you like, but it is a sr...
I agree with Ulrich. This was an option in Version 2 and to me is a much desired freature. The list in the joins suggestions would work much better too. I have a standared that all table contain a created and modified date columns, and I'm being presented with the following: .[Created_By] = [c].[Created_By] .[Created_Dt] = [c].[Created_Dt] .[Modified_By] = [c].[Modified_By] .[Modified_Dt] = [c].[Modified_Dt] .[Ticket_Id] = [c].[Ticket_Id]
Where Ticket_Id is the only PK/FK relationship. I know I can turn off matching column names but if the PK was first, this would not be necesary.
Dave / comments
I agree with Ulrich. This was an option in Version 2 and to me is a much desired freature. The list in the joins suggestions would work much better too. I have a standared that all table contain...