Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
Home
Discussion GroupsVB SyntaxEnterprise DevelopmentDatabase AccessControlsCOMWin APICrystal ReportDeploymentGeneralGeneral 2
Related Topics
VB.NET / ASP.NETMS SQL ServerMS AccessOther Database ProductsMore Topics ...

VB Forum / Controls / September 2009



Tip: Looking for answers? Try searching our database.

dbgrid error after instaling "cumulative update rollup for VB6"

Thread view: 
Enable EMail Alerts  Start New Thread
Thread rating: 
bartek - 19 Jun 2009 17:46 GMT
after instaling "cumulative update rollup for the Visual Basic 6.0 Service
Pack 6 Runtime Extended Files" http://support.microsoft.com/kb/957924/en-us 
dbgrid.ocx (new version is 5.01.9813) doesn't work. The colums simply
disappear in run time.
Veriosn 8104 is ok

I can connect dbgrid to the data control and to the access 97/2K database.
I can "retrieve fields" to see the captions, but after Run then columns are
1px width on the left site without any data.
Ralph - 19 Jun 2009 18:19 GMT
> after instaling "cumulative update rollup for the Visual Basic 6.0 Service
> Pack 6 Runtime Extended Files" http://support.microsoft.com/kb/957924/en-us
[quoted text clipped - 5 lines]
> I can "retrieve fields" to see the captions, but after Run then columns are
> 1px width on the left site without any data.

Did you also install VB SP6?
Are you using the DataEnvironment?
Are you using DAO or ADO?
Is your query returning any data?

You can check the latter rather quickly.
Place a break just after you retrieve the query, ie, set the Recordset.
Then in the Intermediate window type:
    ? <recordset>!<some_column>
For example: if your Recordset identifier/variable is "rst", and you have a
column named "Name", that is suppose to contain "John" then type this ...
  ? rst!Name
"John" should print out in the intermediate window.

You say you are connecting to the "access 97/2K database". This is a bit
worrisome as MSAccess 97 creates Jet 3 formatted files, and MSAccess 2K
(while it can work with Jet 3 files) defaults to Jet 4 formatted files. To
preserve sanity make sure you are dealing with one or the other format until
you isolate the problem. <smile>

hth
-ralph
bartek - 19 Jun 2009 22:36 GMT
> Did you also install VB SP6?
Yes, vb 6.0

> Are you using the DataEnvironment?
No

> Are you using DAO or ADO?
Data control is DAO.

> Is your query returning any data?
Data control recordset is OK.
On the next test I found that it works without "retrieve fields" :)
Grid placed on the form connected to datasource shows records, but after
"retrieve fields" it doesn't. Then after "Clear field " records are ok again.
Sombody switches the flag when read the data? ;)

> You can check the latter rather quickly.
> Place a break just after you retrieve the query, ie, set the Recordset.
there is no code on the zmall test project: database, form, data control
connected to database and table and grid connected to datasource

> You say you are connecting to the "access 97/2K database". This is a bit worrisome ....
I wanted to say that it doesn't matter which jet is used.

simple the ocx work
Ralph - 20 Jun 2009 00:35 GMT
> > Did you also install VB SP6?
> Yes, vb 6.0
[quoted text clipped - 21 lines]
>
> simple the ocx work

If you using the DataEnvironment then you are using ADO. The dbGrid control
was originally DAO (and contains some DAO 'roots'). The new control can use
ADODB or DAO Recordsets.

Ok, I probably missed something, but I think you are saying that the DBGrid
control, alternates between showing and not showing data depending on
various 'clicks' or actions. This is normal for your kind of setup. For more
normal behavior you should add refresh, etc to code.

-ralph
bartek - 22 Jun 2009 10:36 GMT
>> If you using the DataEnvironment then you are using ADO. The dbGrid control
>> was originally DAO (and contains some DAO 'roots'). The new control can use
>> ADODB or DAO Recordsets.
I'm not using DataEnvironment. I'm using DAO

There are what i'm doing on the test project.
0. dbgrid32cx version 9813
1. I place "data control" on the form
2. Connect it to databse setting "databasename" and  "RecordSource"
3. then dbgird on then form and connect it to  "data1" setting  "dataSource"
4. Right-click dbgrid and do "retrieve field" - captions of columns are filled
5. Run Application - no data in the grid, and no captions.
No code. This combination works with old version of ocx
6. Stop application. Right-click dbgrid and do "Clear field"
7. Run Application - there are data in the grid :)

The old version of "dbgrid32cx" no. 8104 shows correct data in both situation.
Adding dbgrid1.refresh does'n help.
Ralph - 22 Jun 2009 14:29 GMT
> >> If you using the DataEnvironment then you are using ADO. The dbGrid control
> >> was originally DAO (and contains some DAO 'roots'). The new control can use
> >> ADODB or DAO Recordsets.
> I'm not using DataEnvironment. I'm using DAO

Ha.

I'm a dufus. I read your reply and my brain translated into saying you were
using DataEnvironment. Sorry.

> There are what i'm doing on the test project.
> 0. dbgrid32cx version 9813
[quoted text clipped - 9 lines]
> The old version of "dbgrid32cx" no. 8104 shows correct data in both situation.
> Adding dbgrid1.refresh does'n help.

My reply was based on the following condition: (not saying this is you, only
what can occasionally cause this problem, and why I gave the silly answer I
did.)

Say a developer creates a simple project with one Form, a couple of action
buttons, and a DBGrid. And within the design-time Property settings define
the database name, etc. During runtime - data (captions, cells) - may behave
strangely with various retrievals/clear/re-populate actions invoked by the
buttons causing data to appear and disappear, forcing one to "micro-manage"
the bounding. (It is as though the control is always one step behind.)

But that is not be the case here, and I apologize for the misunderstanding.
(I also have mostly used DE or straight ADO for "data-binding" and this also
colored my thinking. But enough whinning. I apologize for sending you off
track. lol)

There is a difference between the old version and the new version. Simply
put the difference is the control no longer supports a "partial bounded"
mode.

Try this:
During design when you right-click "Retrieve Fields", then right-click again
and select "Edit". Then delete, add, resize, ... Then select Properties and
configure.
Then run your application. You should see whatever you designed.
Alternately go back and "Clear Fields", and like what you experienced - a
"default" view will appear.
ie, you can't have it both ways it must be either "unconfigured" or "fully
configured".

Also to be on the safe side - destroy any "oca" files you might have hanging
about. VB will recreate these as needed.

hth
-ralph
Ralph - 22 Jun 2009 16:20 GMT
<snipped>
> There is a difference between the old version and the new version. Simply
> put the difference is the control no longer supports a "partial bounded"
> mode.

Substitute "unbound" for "partial bounded" for accuracy.
bartek - 22 Jun 2009 19:28 GMT
> (I also have mostly used DE or straight ADO for "data-binding" and this also
> colored my thinking.
We have created this project before ADO (this is the reason I told before
about access 97) and has worked for 10 years... till now :(

>Try this
> During design when you right-click "Retrieve Fields", then right-click again
> and select "Edit". Then delete, add, resize, ... Then select Properties and
> configure.
> Then run your application.
I know how to set properties. This it not a problem.
You can see the efect on
http://www.vbforums.com/showthread.php?p=3541870#post3541870
But Your words about Properties allow me to find the bug....:)... which I
cannot correct :(

"Retrieve fields" takes information about columns and fill the the Columns
collection in PropertyPages, but do not fill the "DateField" for each column,
and more... when I manualy set DateField for Column0 and press "Apply" or
"OK" or change the column the information in DateField dissapear.
Also in my 10 years old project all information about "Columns-DateField"
association has dissapeared. So, this is the problem: With new version of OCX
I'm not able to set the DateField for columns :(

> Also to be on the safe side - destroy any "oca" files you might have hanging
> about. VB will recreate these as needed.
I've deleted old oca, but nothing happened after re-creation.
I also find that this is not "my system problem" because i've innstaled a
new system with new VB instance + VBSP6 and everything is the same.

thanks in advance
bartek
Ralph - 22 Jun 2009 19:46 GMT
> > (I also have mostly used DE or straight ADO for "data-binding" and this also
> > colored my thinking.
[quoted text clipped - 25 lines]
> I also find that this is not "my system problem" because i've innstaled a
> new system with new VB instance + VBSP6 and everything is the same.

Yeah, again I'll apologize for my misunderstanding, And I certainly didn't
mean to infer you didn't know how to set properties, just wanted to know
what would happen if you "fully" bound all the information during design
time.

If I understand you correctly this time - everything seems to work, except a
"Date Field". I can't test it at the moment but I'll go back and piddle when
I get the chance.

I vaguely remember (now that you have jogged my memory) there were a number
of howls of complaint with the new control from those using DAO. I bet there
is an article or two on the web talking about this very issue. That is if
you can find them amongst the VB.Net chatter, and people confusing the
control name. lol

Sry I wasn't of more help.
-ralph
bartek - 23 Jun 2009 14:23 GMT
> I vaguely remember (now that you have jogged my memory) there were a number
of howls of complaint with the new control from those using DAO.

I've found a lot of information about this new package od controls, but only
that they've stoped working in VBA project after client's system update  (In
fact I've got this in one of my clients computer), so this means for me that
we should change the version of OCX to new one, but .....

Ralph, thanks for your Help
I'll wait for "cumulative pack - v3" :)
Bartek
Mauro Marini - 03 Aug 2009 12:25 GMT
Hi Bartek.
Unfortunatly i have exactely the same problem... and i cannot solve it. The
same happend to me a couple of months ago. I cannot be sure cause at that
time i've done a lot of thing to find a solution, but seems to be that using
the fie "... .reg" contained in the "old controls" folder of the MS VB6 PRO
CD, it was working. Today, apparently without any reason, the problem is
camed out again... But the solution i was talking about befor doesn't work!
And i am a bit disperate cause I have a lot of important project to be
mantained... a I cannot change controls... NOT NOW.
Without a solution to this problem I cannot compile new running versions of
my programs...
Did you find anything else?
You says that the probelm came with the installation of cumulative patches
for VS6.... did you try to uninstall this update?
Thank you.
Regards.

Mauro Marini.
StarNet s.r.l.
Rubano - Padova - Italia

> > I vaguely remember (now that you have jogged my memory) there were a number
> of howls of complaint with the new control from those using DAO.
[quoted text clipped - 7 lines]
> I'll wait for "cumulative pack - v3" :)
> Bartek
bartek - 10 Sep 2009 13:44 GMT
Hi,

>> You says that the probelm came with the installation of cumulative patches
for VS6.... did you try to uninstall this update?

You cannot uninstall this patch.
I have one special computer with VB6.0 without this patch to compile old
projects, I'm waiting for "cumulative patch v. 03" :) and praying for correct
working one my clients computers ;)

I'll post something here if I find the solution.

Bartek
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2010 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.