When should I lock/unlock, hide or unhide columns in DataGrid?

I am working on an old VB6 application. Clearly no maintenance was held and the most of the code is placed in one form which has like 5000 lines. This is makes quite hard to find bugs.

I can see that the DataGrid is the main part of the form and the code contains some logic for locking/unlocking and hiding/hiding columns when a certain condition is met.

This data grid is connected to a predefined ADODC(placed on the same form) component which uses string query to load data from a table.

Also when this form loads there are additional two queries that should fill the ADODC component on form load.
I found that at some case the ADODC is with zero rows since the query doesn't find any data for the given case, but logic for locking/unlocking and hiding/hiding is still executed even there are no data to display in the DataGrid.
This causes application failure with error

Code:

---

"datagrid runtime error "6160" Data Access Error"

---

I tried to add some validation with the ADODC component like:

Code:

---

if MyAdodc.Recordset.RecordCount > 0 then
    ' do left over application stuff
else
    Exit sub
end if

---

This however ended with another DataGrid control error:

Code:

---

The current row is not available.

---

Is there something I should follow when using DataGrid and ADODC or this is simply a bad programming and badly designed flow of control?

Actually, having only one form makes it EASIER (per se) to find bugs.

Odd....this error is not received otherwise?

Does your subroutine call another sub BEFORE your new IF statement? If so, then whatever would normally have been done if there were no records, still tries to execute.

What is the line on which your error occurs? In what sub is that line included?

Is it at all possible for you to create a dummy database and set your ADODC control to it, and then zip and attach the project (less the current database and any executables)?

Which line caused the new error? Is it: if MyAdodc.Recordset.RecordCount > 0 then

Else, it is always helpful to us if you provide the exact line that caused the error

There are some typical checks that can be made:
1. If MyAdodc.RecordSet Is Nothing Then ' no recordset was created/returned
2. If MyAdodc.RecordSet.EOF = True And MyAdodc.RecordSet.BOF = True Then ' no records in the recordset

maybe you could do a count query first, if 0 don't execute the select query?

Hmm, I made some code to reproduce how the actual application works. It is similar but I get different error message now.

Basically two forms are in the scenario. One is the main form and the second form is where you display the DataGrid component and load data into ADODC component.

Main form:
Attachment 172533

DataGrid form:
Attachment 172525
Attachment 172529
Attachment 172531

If you check closely the commented out line in the DataGrid Form onLoad event method, when I un-comment it, it fails with error message:

Attachment 172535

I get data access error in the actual application.
Is this the right way to work with ADODC and DataGrid? I mean modifying cell properties on the go and changing its data also on the go?

Should I remove ADODC and work with RecordSet instead?

I'm no DataGrid user. I would check the value of DataGrid1.Columns.Count. I would also check the recordset for being empty. In addition, recommend not returning all fields (i.e., Select * From ...) if you don't need all fields.

Per MSDN

Quote:

---

*Note* If you set any of the DataGrid column properties at design time, you will need to set all of them in order to maintain the current settings.

---

Documentation: https://docs.microsoft.com/en-us/pre...ectedfrom=MSDN

The DataGrid doesn't have a problem with an empty query. I wonder if you have an older version that isn't patched up to SP6?

Quote:

---

Should I remove ADODC and work with RecordSet instead?

---

"I" would. Like LaVolpe, I am not a user of VB6's datagrid. To ME, it is less flexible (but others may disagree). When I work with recordsets, I KNOW what my data is when returned (easy to check).

I did NOT look at your error, but simply added MY opinion (we all have those) on your question above.

Sam

Hmm, it might be yes. But only one OCX component circles around and its called MSDATGRD.OCX.

Also could faulty installation be the problem when using the application itself?

Only when Windows 7 is freshly restarted, the installation of VB6 app package gets installed without problem.

When i uninstall and install the app again, I get warning messages that MSDATGRD.OCX, MSFLXGRD.OCX, MSADODC.OCX are occupied by some process as if previous installation doesn't clean references to these files.