Dear Fellow Components,
Judging by the number of related posts, sluggish performance of True DB Grid loading is legendary. I use True DB Grid 7.0, unbound mode, in Visual Basic 6.0. I know why it sometimes takes forever to load this control. Consider this easy piece of code:
Dim TDBGColumn As TrueDBGrid70.Column
For I = 1 To NVar Set TDBGColumn = MyForm.TDBGrid1.Columns.Add(I - 1) Next INothing fancy, right? But this is the slowest line of code in an entire application spanning hundreds of thousands of code lines! Finally, I used Procmon (great tool!) to peek under the sheets: this tool captures and records each system event under Windows. Here is what happens during _each_iteration_:
QueryOpen C:\Program Files\MyApplication\tdbg7.ocx NAME NOT FOUND QueryOpen C:\MyDataFiles\tdbg7.ocx NAME NOT FOUND QueryOpen C:\WINDOWS\system32\tdbg7.ocx SUCCESS CreationTime: 7/24/2008 10:59:37 AM, LastAccessTime: 10/6/2008 4:59:42 PM, LastWriteTime: 6/10/2003 10:27:16 AM, ChangeTime: 7/24/2008 3:51:04 PM, AllocationSize: 925,696, EndOfFile: 922,088, FileAttributes: ACreateFile C:\WINDOWS\system32\tdbg7.ocx SUCCESS Access: Generic Read, Disposition: Open, Options: Synchronous IO Non-Alert, Non-Directory File, Attributes: n/a, ShareMode: Read, Write, AllocationSize: n/aCreateFile C:\WINDOWS\system32\tdbg7.ocx SUCCESS Access: Read Data/List Directory, Synchronize, Disposition: Open, Options: Synchronous IO Non-Alert, Non-Directory File, Complete If Oplocked, Attributes: n/a, ShareMode: Read, AllocationSize: n/aQueryFileInternalInformationFile C:\WINDOWS\system32\tdbg7.ocx SUCCESS IndexNumber: 0x40000000109d1CloseFile C:\WINDOWS\system32\tdbg7.ocx SUCCESS ReadFile C:\WINDOWS\system32\tdbg7.ocx SUCCESS Offset: 0, Length: 64CloseFile C:\WINDOWS\system32\tdbg7.ocx SUCCESS QueryOpen C:\Program Files\MyApplication\tdbg7.ocx NAME NOT FOUND QueryOpen C:\MyDataFiles\tdbg7.ocx NAME NOT FOUND QueryOpen C:\WINDOWS\system32\tdbg7.ocx SUCCESS CreationTime: 7/24/2008 10:59:37 AM, LastAccessTime: 10/6/2008 4:59:49 PM, LastWriteTime: 6/10/2003 10:27:16 AM, ChangeTime: 7/24/2008 3:51:04 PM, AllocationSize: 925,696, EndOfFile: 922,088, FileAttributes: ACreateFile C:\WINDOWS\system32\tdbg7.ocx SUCCESS Access: Generic Read, Disposition: Open, Options: Synchronous IO Non-Alert, Non-Directory File, Attributes: n/a, ShareMode: Read, Write, AllocationSize: n/aCreateFile C:\WINDOWS\system32\tdbg7.ocx SUCCESS Access: Read Data/List Directory, Synchronize, Disposition: Open, Options: Synchronous IO Non-Alert, Non-Directory File, Complete If Oplocked, Attributes: n/a, ShareMode: Read, AllocationSize: n/aQueryFileInternalInformationFile C:\WINDOWS\system32\tdbg7.ocx SUCCESS IndexNumber: 0x40000000109d1CloseFile C:\WINDOWS\system32\tdbg7.ocx SUCCESS ReadFile C:\WINDOWS\system32\tdbg7.ocx SUCCESS Offset: 0, Length: 64CloseFile C:\WINDOWS\system32\tdbg7.ocx SUCCESS
(Copy the above and paste into Excel for better view.) So. During _each_iteration_ Windows does the following:
1) It searches the application folder, C:\Program Files\MyApplication\, for tdbg7.ocx and it does not find it
2) It searches current working directory, C:\MyDataFiles\, for tdbg7.ocx and it does not find it, either
3) Finally, it searches C:\WINDOWS\system32\ for tdbg7.ocx, finds it and opens it
4) It reads tdbg7.ocx and closes it
5) For some bleeping reason it repeats it again
All of the above to add just one column! In this particular test NVar = 400 columns, hence the above simple loop results in a whooping 800 disk searches and file open/read/close operations! No wonder it's slow. The worst part is that some customers store their data files on a network drive which means that C:\MyDataFiles\ is replaced by a slow network folder... They report waiting times in the order of 10 minutes just to load the grid!
Correct me if I'm wrong, but isn't the ActiveX component supposed to be loaded _once_ - at the beginning of program execution - and stay in memory for better performance? Why does it have to be accessed on disk for every tiny operation on the grid?
Hoping for enlightening answers,
SimPlus