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
> 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
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
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.
"bartek" <bar...@discussions.microsoft.com> wrote in message
news:DF78F5F2-733B-4C90...@microsoft.com...
> >> 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
> 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.
>
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" <nt_cons...@yahoo.com> wrote in message
news:%23%23DBE3z8...@TK2MSFTNGP04.phx.gbl...
>
<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.
>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
"bartek" <bar...@discussions.microsoft.com> wrote in message
news:623F5249-5A78-4AAC...@microsoft.com...
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
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.
StarNet s.r.l.
Rubano - Padova - Italia
>> 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