At 09:43 2018-10-09, "Paul H. Tarver" paul@tpcqpc.com wrote:
Good article. I have to admit sometimes I cheat and have more than five indexes with one column each when I'm optimizing Rushmore on temporary cursors, but otherwise, this is really good advice.
This is stupid advice. An arbitrary number of indexes is not correct. Instead, determine how many indexes are required and create that many.
Keeping it simple, keeps it fast.
But it might not meet the needs of the users.
[snip]
Sincerely,
Gene Wirchenko
Gene, you may have the point or missed it totally, not sure. The number of indexes you maintain is a performance hit when you have a lot of data in a table and your index is SELDOM used. The more complex the index is for a use at EOM operation may impact the daily CRUD operations of that table for all the other days of the week. Here are identical clustered and non clustered indexes
CREATE UNIQUE CLUSTERED INDEX [Itwhinh4331a] ON [dbo].[twhinh433] ( [t_shpm] ASC, [t_pono] ASC, [t_boml] ASC, [t_dssq] ASC, [t_serl] ASC )WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, IGNORE_DUP_KEY = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY] GO
Here you have 5 columns to define unique in one of my LOTS consumption tables. This is only one index and the Shipment number will direct the natural order for the output of this index.
The article didn't go into the basics of index NAZI techniques because Brent sells a class for learning just that at the very bottom of the blog. :)
When you get into actual index tuning to deliver top performance the little things are what get adjusted to give you that big payoff in the end. When you are doing EOM operations and truncate the working tables to pull in last months data, having fewer indexes will speed things up. The generation of all the leaves that are required to grow, break as they expand while the table takes in 100,000 rows of data slows down the process. The worst ones are nvarchar data for a name or address. I have found that it is better to drop those indexes on the front end and generate them after the data is inserted.
YMMV
On Tue, Oct 9, 2018 at 9:15 PM Gene Wirchenko genew@telus.net wrote:
At 09:43 2018-10-09, "Paul H. Tarver" paul@tpcqpc.com wrote:
Good article. I have to admit sometimes I cheat and have more than five indexes with one column each when I'm optimizing Rushmore on temporary cursors, but otherwise, this is really good advice.
This is stupid advice. An arbitrary number of indexes is notcorrect. Instead, determine how many indexes are required and create that many.
Keeping it simple, keeps it fast.
But it might not meet the needs of the users.[snip]
Sincerely,
Gene Wirchenko
[excessive quoting removed by server]
For a taste of the future check out SQL Server 2017's index tuning recommendations and the Azure hosted version of SQL Server 2017 that can proactively implement these tuning recommendations on your behalf.
Automatic tuning https://docs.microsoft.com/en-us/sql/relational-databases/automatic-tuning/a...
Malcolm
Lucky for me that we are still on 2012 Enterprise and 2014 standard editions.
I cringe at this " or lets the Database Engine automatically fix performance problems."
I am afraid that it will 1. Generate the index at the WRONG TIME 2. Create many more indexes that consume a great deal of disk space because the tables have close to a billion rows. 3. We have a vendor supplied system and I have to follow their rules to keep our support costs down, hahahahahaha. 4. I would like to get notice on what the machine needs to do and schedule it in proposed downtime. 5. Working better with machines is the only way to advance looking forward, I just want to know when and what might be happening.
On Wed, Oct 10, 2018 at 10:03 AM Malcolm Greene profox@bdurham.com wrote:
For a taste of the future check out SQL Server 2017's index tuning recommendations and the Azure hosted version of SQL Server 2017 that can proactively implement these tuning recommendations on your behalf.
Automatic tuning
https://docs.microsoft.com/en-us/sql/relational-databases/automatic-tuning/a...
Malcolm
[excessive quoting removed by server]
I cringe at this "or lets the Database Engine automatically fix performance problems."
The tuning can be automated or you can just receive recommendations. We're dipping our toes in the water with this feature, but it looks promising.
Malcolm
We are not committed to 2017 as of yet, it takes Infor to give approval to us that we can take that step.
To be honest we are 30-70 at going to the cloud with our ERP in 2020. I am afraid of the bloodletting that will take place next year here helping our vendor learn how to operate both in the cloud as well as on-prem for the variety of products they sell us and where they will run.
Stuff like warehouse automation makes my back tense up. Getting the data from here in our LAN up to there and all of the joy we have today with other systems locking rows that cause us to receive phone calls at night to fix this crap. I do not see our cloud vendor stopping this and it is ALL their SW that does the locking today.
On Wed, Oct 10, 2018 at 10:22 AM Malcolm Greene profox@bdurham.com wrote:
I cringe at this "or lets the Database Engine automatically fix
performance problems."
The tuning can be automated or you can just receive recommendations. We're dipping our toes in the water with this feature, but it looks promising.
Malcolm
[excessive quoting removed by server]
first of all ctrl C & V work as they are supposed to everywhere but this one place:
We have some text boxes on one screen in our program. If you ctrl C (copy) anything from one text box and then ctrl V (paste) it to another text box, the screen goes blank.
Moving the mouse around after the screen is blank has no effect, the screen stays blank. If you happen to click where that text box was, it reappears.
Then if you move your mouse to the side of the screen, the screen reappears (but not the info you pasted). Then if you leave that screen and then go back to that screen, everything seems normal.
Someone just today noticed this. This has not been reported before in many years. The same source code has been compiled in several versions of VFP and several windows OS back to Win 2000.
[excessive quoting removed by server]
I left out some important info. The box that contains the info you want to copy is a memo text box. When you exceed the allowed amount, we pop up a box that allows unlimited data entry. If you copy that, the crazy stuff happens.
______________________________________
first of all ctrl C & V work as they are supposed to everywhere but this one place:
We have some text boxes on one screen in our program. If you ctrl C (copy) anything from one text box and then ctrl V (paste) it to another text box, the screen goes blank.
Moving the mouse around after the screen is blank has no effect, the screen stays blank. If you happen to click where that text box was, it reappears.
Then if you move your mouse to the side of the screen, the screen reappears (but not the info you pasted). Then if you leave that screen and then go back to that screen, everything seems normal.
Someone just today noticed this. This has not been reported before in many years. The same source code has been compiled in several versions of VFP and several windows OS back to Win 2000.
[excessive quoting removed by server]
You're description of the problem reminds me of what the LockScreen property can do to a form. I have seen some odd behaviors with Modal forms opening other Modal forms, but not that specific behavior.
Can you give some more detail about how these forms are built? Is there any code that changes the LockScreen property? Is this in Screen, or a top-level screen?
-----Original Message----- From: ProfoxTech [mailto:profoxtech-bounces@leafe.com] On Behalf Of Ken McGinnis Sent: Wednesday, October 10, 2018 1:08 PM To: profoxtech@leafe.com Subject: Fwd: question about crazy ctrl C and ctrl V thing in the vfp9 sp2 program
I left out some important info. The box that contains the info you want to copy is a memo text box. When you exceed the allowed amount, we pop up a box that allows unlimited data entry. If you copy that, the crazy stuff happens.
______________________________________
first of all ctrl C & V work as they are supposed to everywhere but this one place:
We have some text boxes on one screen in our program. If you ctrl C (copy) anything from one text box and then ctrl V (paste) it to another text box, the screen goes blank.
Moving the mouse around after the screen is blank has no effect, the screen stays blank. If you happen to click where that text box was, it reappears.
Then if you move your mouse to the side of the screen, the screen reappears (but not the info you pasted). Then if you leave that screen and then go back to that screen, everything seems normal.
Someone just today noticed this. This has not been reported before in many years. The same source code has been compiled in several versions of VFP and several windows OS back to Win 2000.
[excessive quoting removed by server]
Another thought about this: I know vfp9 sp2 is supposed to fix some issues with how Vista caused problems like this to happen. I wonder if the exe was somehow compiled on vfp9 RTM or sp1. It's been years since I saw this in my own product. I do remember searching and finding workarounds for several Vista UI issues.
-----Original Message----- From: ProfoxTech [mailto:profoxtech-bounces@leafe.com] On Behalf Of Tracy Pearson Sent: Wednesday, October 10, 2018 1:12 PM To: profoxtech@leafe.com Subject: RE: question about crazy ctrl C and ctrl V thing in the vfp9 sp2 program
You're description of the problem reminds me of what the LockScreen property can do to a form. I have seen some odd behaviors with Modal forms opening other Modal forms, but not that specific behavior.
Can you give some more detail about how these forms are built? Is there any code that changes the LockScreen property? Is this in Screen, or a top-level screen?
-----Original Message----- From: ProfoxTech [mailto:profoxtech-bounces@leafe.com] On Behalf Of Ken McGinnis Sent: Wednesday, October 10, 2018 1:08 PM To: profoxtech@leafe.com Subject: Fwd: question about crazy ctrl C and ctrl V thing in the vfp9 sp2 program
I left out some important info. The box that contains the info you want to copy is a memo text box. When you exceed the allowed amount, we pop up a box that allows unlimited data entry. If you copy that, the crazy stuff happens.
______________________________________
first of all ctrl C & V work as they are supposed to everywhere but this one place:
We have some text boxes on one screen in our program. If you ctrl C (copy) anything from one text box and then ctrl V (paste) it to another text box, the screen goes blank.
Moving the mouse around after the screen is blank has no effect, the screen stays blank. If you happen to click where that text box was, it reappears.
Then if you move your mouse to the side of the screen, the screen reappears (but not the info you pasted). Then if you leave that screen and then go back to that screen, everything seems normal.
Someone just today noticed this. This has not been reported before in many years. The same source code has been compiled in several versions of VFP and several windows OS back to Win 2000.
[excessive quoting removed by server]
More info: These are text boxes on the screen with a control source that is a memo record. So if you manually type in 50 char, a text window comes up and allows you to continue typing. Then you press ctrl W and the window closes/saves and the info is in the memo record, no problem. The problem is when you have something (more than 50 char) in your clipboard and you ctrl V (paste) in the text box to force the text window to come up - the crazy stuff happens. Something about pasting is different from manually typing. First time for me and I have been with Fox since the mid 80's all though the various editions.
On 10/10/2018 1:26 PM, Tracy Pearson wrote:
Another thought about this: I know vfp9 sp2 is supposed to fix some issues with how Vista caused problems like this to happen. I wonder if the exe was somehow compiled on vfp9 RTM or sp1. It's been years since I saw this in my own product. I do remember searching and finding workarounds for several Vista UI issues.
-----Original Message----- From: ProfoxTech [mailto:profoxtech-bounces@leafe.com] On Behalf Of Tracy Pearson Sent: Wednesday, October 10, 2018 1:12 PM To: profoxtech@leafe.com Subject: RE: question about crazy ctrl C and ctrl V thing in the vfp9 sp2 program
You're description of the problem reminds me of what the LockScreen property can do to a form. I have seen some odd behaviors with Modal forms opening other Modal forms, but not that specific behavior.
Can you give some more detail about how these forms are built? Is there any code that changes the LockScreen property? Is this in Screen, or a top-level screen?
-----Original Message----- From: ProfoxTech [mailto:profoxtech-bounces@leafe.com] On Behalf Of Ken McGinnis Sent: Wednesday, October 10, 2018 1:08 PM To: profoxtech@leafe.com Subject: Fwd: question about crazy ctrl C and ctrl V thing in the vfp9 sp2 program
I left out some important info. The box that contains the info you want to copy is a memo text box. When you exceed the allowed amount, we pop up a box that allows unlimited data entry. If you copy that, the crazy stuff happens.
first of all ctrl C & V work as they are supposed to everywhere but this one place:
We have some text boxes on one screen in our program. If you ctrl C (copy) anything from one text box and then ctrl V (paste) it to another text box, the screen goes blank.
Moving the mouse around after the screen is blank has no effect, the screen stays blank. If you happen to click where that text box was, it reappears.
Then if you move your mouse to the side of the screen, the screen reappears (but not the info you pasted). Then if you leave that screen and then go back to that screen, everything seems normal.
Someone just today noticed this. This has not been reported before in many years. The same source code has been compiled in several versions of VFP and several windows OS back to Win 2000.
[excessive quoting removed by server]
On Wed, Oct 10, 2018 at 7:10 PM Ken McGinnis kamcginnis@gmail.com wrote:
The problem is when you have something (more than 50 char) in your clipboard and you ctrl V (paste) in the text box to force the text window to come up - the crazy stuff happens. Something about pasting is different from manually typing.
I would guess the routine checking input string length is KeyPress, and KeyPress is launching the new form?
I wonder if, in effect, pasting is firing KeyPress for each character, so you're triggering the routine repeatedly, which is "blocking something."
How about adding a property to the textbox, say, lStringFull, defaulted to .F. that you flip to .T, on the 50th character, then change the logic at the beginning of the KeyPress to:
if ! THIS.lStringFull && already triggered if len(THIS.Value) >=50 THIS.lStringFull = .T. endif
<do your routine>
endif && already triggered
Here is a headline from the ZD net newletter online. http://enews.zdnet.com/ct/49630481:WN1wt1IwN:m:1:716695873:33BB1C05A1399C947BC6F0840CB39C36:r
placeholder http://enews.zdnet.com/ct/49630481:WN1wt1IwN:m:1:716695873:33BB1C05A1399C947BC6F0840CB39C36:r Worst Windows 10 version ever? Microsoft's terrible, horrible, no good, very bad October http://enews.zdnet.com/ct/49630481:WN1wt1IwN:m:1:716695873:33BB1C05A1399C947BC6F0840CB39C36:r
--- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
--- StripMime Report -- processed MIME parts --- multipart/alternative text/plain (text body -- kept) text/html ---
This is stupid advice.
Don't hold back, Gene! Tell us how you really feel. LOL
I think the point of the article was to help remind people to think about indexes before just using them without understanding the effects on performance. Having a rule of thumb like 5 indexes per table would make me stop and consider whether a 6th index was required. If so, then great. But at least I would have thought about the benefits and negatives before doing it. Frankly, reminding people to consider the consequences of their actions is NEVER stupid advice.
Paul H. Tarver Email: paul@tpcqpc.com
-----Original Message----- From: ProfoxTech [mailto:profoxtech-bounces@leafe.com] On Behalf Of Gene Wirchenko Sent: Tuesday, October 09, 2018 9:15 PM To: profoxtech@leafe.com Subject: RE: [NF] How many indexes do you need?
At 09:43 2018-10-09, "Paul H. Tarver" paul@tpcqpc.com wrote:
Good article. I have to admit sometimes I cheat and have more than five indexes with one column each when I'm optimizing Rushmore on temporary cursors, but otherwise, this is really good advice.
This is stupid advice. An arbitrary number of indexes is not correct. Instead, determine how many indexes are required and create that many.
Keeping it simple, keeps it fast.
But it might not meet the needs of the users.
[snip]
Sincerely,
Gene Wirchenko
[excessive quoting removed by server]
-
Gene Wirchenko -
Ken McGinnis -
Malcolm Greene -
Paul H. Tarver -
Stephen Russell -
Ted Roche -
Tracy Pearson