After long time away from trying to learn database i'm back to trying to 
make a simple jobs/contacts/todo list database for personal use at work

tried to run the dhSqlite demo(right clikced the vbp- hit Start with full 
compile)

got the following compile error at this line:
Private Sub AdoDC_FieldChangeComplete(ByVal cFields As Long, Fields As 
Variant, ByVal pError As ADODB.Error, adStatus As ADODB.EventStatusEnum, 
ByVal pRecordset As ADODB.Recordset

error:
Procedure declaration does not match description of event ... having same 
name

the readme.txt has last line: (in Mar/2008)

is that the current incarnation?

I copied sqlite dll and directcom to system32
I copied dhRichClient to my "registerd dlls" folder and regsvr'ed
the project correctly finds my path to dhRichClient when I open the vbp and 
look at references

what did i do wrong?
thanks
mark

This seems to be unrelated to dhSqliteDemo. That error typically show up if 
you first used a control without setting the Index property, then decided 
later to use it. In this case, Index parameter must be the first parameter. 
Make VB generate the updated event declaration using the code window combo 
boxes, then replace the declaration.

"mp" <nospam@Thanks.com> schrieb im Newsbeitrag
news:u3hFxz9bKHA.2188@TK2MSFTNGP04.phx.gbl...
> After long time away from trying to learn database i'm back
> to trying to make a simple jobs/contacts/todo list database
> for personal use at work
>
> tried to run the dhSqlite demo(right clikced the vbp- hit Start with
> full compile)

First ensure, that you're using the latest Binaries and Demos from:
www.thecommon.net/3.html

Then install all of the Binaries into a separate Folder on
your local Disk, as e.g on:
C:\dhRichClient3\...
To register the COM-Dlls you could run the included
Register.bat file - or do it "by hand" with your tool
of choice.

Then proceed with the new downloaded Demos - you
don't need to put the Demo-zip-contents into the Folder
I've just mentioned above - but doing so would work
too of course.

Then start the NWind-Demo-project in the \SQLite
Demo-Folder.

The error-message you've mentioned (ADODC-event-
related) presumable has nothing to do with the RichClient-
toolset. It's probably caused by a not matching Interface-
Definition of my older Demo-Project and the ADODC-Control-
Interface-Specs on your local dev-machine. Not sure now,
if I have a version which is not current (my VB6-install is
updated up to SP5) - or if you maybe have an older Version
of the VB6-Servicepacks installed, so that the ADODC-Ctl
on your machine is incompatible regarding the interface.

If you have an ADO-DC-Version which is "marked" in the
Component-Viewer different than (SP-4), then it could make
sense to update your VB6-package first (including a newer
ADODC) - or if that does not help, then just comment
out this Event-Procedure in question - and then re-select
the new Event-Procedure from the DropDown-Combo
at the TopRight-Corner of your Editor-Window. Then
fill in the Code of the outcommented Event-Proc into
the new, now matching one.

Now, looking at my updated dhRichClient3-Demo-Code,
I've just discovered - that the Form with the ADODC-Demo
is removed in this new version. So the just written stuff
above is not relevant anymore ("just for the archives").

The older Demo had a comparison between two "DC-
DataBinding-Forms" (one for ADO and one for the
SQLite-Objects) - but as just said, the ADO-DC-Form is
now removed (only the SQLite-DC-DemoForm remains).

The only remaining "comparison-forms" are the ones
which work against a DataGrid (Select-Performance) -
and the two nearly identical Insert-Performance-Demo-
Forms (all working against identical NorthWind-DB-
Data).

Let me know, when you have problems with the setup
of the new RichClient3 - maybe remove your older
RichClient beforehand to stay clean on your system.

The new version is "calling-compatible" to the older
RichClient - only the BinCompatibility was broken,
therefore it should be enough, if you switch your
older Projects, which maybe incorporate the
dhRichClient-Reference - in your project-settings
to the new dhRichClient3-reference.
But a parallel install would work too - no problem
here with that.

Olaf

"Schmidt" <sss@online.de> wrote in message 
news:ubm$k3$bKHA.2160@TK2MSFTNGP02.phx.gbl...
>
> "mp" <nospam@Thanks.com> schrieb im Newsbeitrag
> news:u3hFxz9bKHA.2188@TK2MSFTNGP04.phx.gbl...
>> After long time away from trying to learn database i'm back
snip
>
> First ensure, that you're using the latest Binaries and Demos from:
> www.thecommon.net/3.html
>

thanks got em, will proceed with installs

> Then install all of the Binaries into a separate Folder on
> your local Disk, as e.g on:
> C:\dhRichClient3\...
> To register the COM-Dlls you could run the included
> Register.bat file - or do it "by hand" with your tool
> of choice.
>

> if I have a version which is not current (my VB6-install is
> updated up to SP5) - or if you maybe have an older Version
> of the VB6-Servicepacks installed, so that the ADODC-Ctl
> on your machine is incompatible regarding the interface.

i'm pretty sure i'm on sp5 unless i forgot to load that the last time i 
reformatted this box
how can i check in the ide? help|about shows  version 8176 vba:retail 
6.0.8169 forms3:2.01
i guess i could just rerun sp5 without fear of damage to make sure?

> If you have an ADO-DC-Version which is "marked" in the
> Component-Viewer different than (SP-4), then it could make
> sense to update your VB6-package first (including a newer
> ADODC)

sorry for my ignorance, how do i check the ado-dc version?

 snip

> Let me know, when you have problems with the setup
> of the new RichClient3 - maybe remove your older
> RichClient beforehand to stay clean on your system.
>
> The new version is "calling-compatible" to the older
> RichClient - only the BinCompatibility was broken,
> therefore it should be enough, if you switch your
> older Projects, which maybe incorporate the
> dhRichClient-Reference - in your project-settings
> to the new dhRichClient3-reference.
> But a parallel install would work too - no problem
> here with that.
>
> Olaf
>

thanks again
mark 

I see that you are using "Controls.Add" method to add the ADODC control. I 
doubt that the GUID changed because of binary compatibility issues. In MS 
December 2008 Rollup update, there is a mention of a bug when "Controls.Add" 
is used, perhaps the OP has that update. I tested this update with Winsock 
control to see if Load statement is effected(to load more sockets), and I 
didn't get any errors after applying Dec 2008 and May 2009 updates, so 
perhaps it only effect "Controls.Add". I didn't test "Controls.Add".

Description of the cumulative update rollup for the Visual Basic 6.0 Service 
Pack 6 Runtime Extended Files
http://support.microsoft.com/kb/957924

"mp" <nospam@Thanks.com> wrote in message 
news:OIWBz0DcKHA.1596@TK2MSFTNGP06.phx.gbl...
> how can i check in the ide? help|about shows  version 8176 vba:retail 
> 6.0.8169 forms3:2.01

That explains the error then, you need the stand alone VB6, not VBA to use 
the ADODC control, and many of VB6 controls.

"Nobody" <nobody@nobody.com> wrote in message 
news:%23A2s17DcKHA.5656@TK2MSFTNGP04.phx.gbl...
> "mp" <nospam@Thanks.com> wrote in message 
> news:OIWBz0DcKHA.1596@TK2MSFTNGP06.phx.gbl...
>> how can i check in the ide? help|about shows  version 8176 vba:retail 
>> 6.0.8169 forms3:2.01
>
> That explains the error then, you need the stand alone VB6, not VBA to use 
> the ADODC control, and many of VB6 controls.

that is stand alone vb6 enterprise
in your help|about box you dont have a reference to the vba version for that 
vb6?
i assumed the vba refernece was due to the fact that vb is built on vba 
namespace or whatever it's called
i don't know the right term but am referring to:
ie Left$(string,x) is VBA.Left

"Nobody" <nobody@nobody.com> wrote in message 
news:eqc4m5DcKHA.2160@TK2MSFTNGP02.phx.gbl...
>I see that you are using "Controls.Add" method to add the ADODC control. I 
>doubt that the GUID changed because of binary compatibility issues. In MS 
>December 2008 Rollup update, there is a mention of a bug when 
>"Controls.Add" is used, perhaps the OP has that update. I tested this 
>update with Winsock control to see if Load statement is effected(to load 
>more sockets), and I didn't get any errors after applying Dec 2008 and May 
>2009 updates, so perhaps it only effect "Controls.Add". I didn't test 
>"Controls.Add".
>
> Description of the cumulative update rollup for the Visual Basic 6.0 
> Service Pack 6 Runtime Extended Files
> http://support.microsoft.com/kb/957924

i've always avoided running sp6 since i heard here through the years that 
there were problems with it
i don't know enough to know what they were or if it would affect me but just 
figured the concensus here was stay with sp5
however i have done windows updates on occasion...could they have 
surreptitiously updated vb service pack in one of those?

it may be i've forgotten to reapply sp5, waiting to hear how to tell what sp 
is active.
seems there should be some version number i could look at but dont' know

thanks
mark 

"mp" <nospam@Thanks.com> wrote in message
news:%23$X0xOEcKHA.4880@TK2MSFTNGP05.phx.gbl...
>
> "Nobody" <nobody@nobody.com> wrote in message
> news:%23A2s17DcKHA.5656@TK2MSFTNGP04.phx.gbl...
> > "mp" <nospam@Thanks.com> wrote in message
> > news:OIWBz0DcKHA.1596@TK2MSFTNGP06.phx.gbl...
> >> how can i check in the ide? help|about shows  version 8176 vba:retail
> >> 6.0.8169 forms3:2.01
> >
> > That explains the error then, you need the stand alone VB6, not VBA to
use
> > the ADODC control, and many of VB6 controls.
>
> that is stand alone vb6 enterprise
> in your help|about box you dont have a reference to the vba version for
that
> vb6?
> i assumed the vba refernece was due to the fact that vb is built on vba
> namespace or whatever it's called
> i don't know the right term but am referring to:
> ie Left$(string,x) is VBA.Left
>

yep.

[
 Ha, I totally forgot about that showing up in VB6 Help/About.
 Would have helped during an earlier attempt to enlighten some .Net fool.
]

-ralph

"mp" <nospam@Thanks.com> wrote in message
news:%23V6WxQEcKHA.1596@TK2MSFTNGP06.phx.gbl...
>
> "Nobody" <nobody@nobody.com> wrote in message
> news:eqc4m5DcKHA.2160@TK2MSFTNGP02.phx.gbl...
> >I see that you are using "Controls.Add" method to add the ADODC control.
I
> >doubt that the GUID changed because of binary compatibility issues. In MS
> >December 2008 Rollup update, there is a mention of a bug when
> >"Controls.Add" is used, perhaps the OP has that update. I tested this
> >update with Winsock control to see if Load statement is effected(to load
> >more sockets), and I didn't get any errors after applying Dec 2008 and
May
> >2009 updates, so perhaps it only effect "Controls.Add". I didn't test
> >"Controls.Add".
> >
> > Description of the cumulative update rollup for the Visual Basic 6.0
> > Service Pack 6 Runtime Extended Files
> > http://support.microsoft.com/kb/957924
>
> i've always avoided running sp6 since i heard here through the years that
> there were problems with it
> i don't know enough to know what they were or if it would affect me but
just
> figured the concensus here was stay with sp5
> however i have done windows updates on occasion...could they have
> surreptitiously updated vb service pack in one of those?
>
> it may be i've forgotten to reapply sp5, waiting to hear how to tell what
sp
> is active.
> seems there should be some version number i could look at but dont' know
>

The SP shows up in the Help/About dialog at the top in paranenthsis. Also on
the splash screen - I think - but it goes by too quickly on this machine to
check.

The basic issues with upgrading to SP6 were relatively minor, and most often
occurred with existing projects in development. Also not all problems were
known when it first appeared, so not much help if one did have a problem.
And overall there wasn't much that SP6 brought that was new or improved. -
thus the general consensus was - if it ain't broke, why go there?

Since then most issues/problems are documented - you can find a fix online
or get help in this group. Second, SP6 "versions" of the runtime components
are now installed with the new Windows O/S. You can actually avoid some
other minor exotic issues with SP5 on Vista and Win7 if you compile against
VB SP6.

Personally if you are writing for XP SP1+/Vista/Win7 I would upgrade to SP6.

Of course it depends on what your app is doing - it is always possible your
app is riddled with "exceptions". And like all SPs commonly a PITA to go
back. <g>

-ralph

"mp" <nospam@Thanks.com> schrieb im Newsbeitrag
news:OIWBz0DcKHA.1596@TK2MSFTNGP06.phx.gbl...

> > First ensure, that you're using the latest Binaries and
> > Demos from:
> > www.thecommon.net/3.html
> >
>
> thanks got em, will proceed with installs

Ok, in that case the problem should remain a more
or less theoretical one, since the newer SQLite-
NWind-Demo-Application from the link above
does not contain the ADODC-DemoForm anymore.

I've also switched this new SQLite-Demo from the former
dynamic Control-Loading to a normal, static one - to reduce
such potential problems you just experienced with the
older Demo-Code.

Hope everything will work "right out of the box" now
with the new (version3-related) Demo-Sources.

Olaf

"mp" <nospam@Thanks.com> wrote in message 
news:%23V6WxQEcKHA.1596@TK2MSFTNGP06.phx.gbl...
> however i have done windows updates on occasion...could they have 
> surreptitiously updated vb service pack in one of those?

Not the service pack, but some files. Check the version of the file that you 
have. Msadodc.ocx is one of the files that is updated. See the article for 
version number.

"Nobody" <nobody@nobody.com> wrote in message 
news:u$LwfoHcKHA.5796@TK2MSFTNGP06.phx.gbl...
> "mp" <nospam@Thanks.com> wrote in message 
> news:%23V6WxQEcKHA.1596@TK2MSFTNGP06.phx.gbl...
>> however i have done windows updates on occasion...could they have 
>> surreptitiously updated vb service pack in one of those?
>
> Not the service pack, but some files. Check the version of the file that 
> you have. Msadodc.ocx is one of the files that is updated. See the article 
> for version number.
>

anyway as Olaf said it's a non issue as he's removed the adodc from new 
samples
am in process of installing the updated version and beginning testing that
thanks everyone for your help
mark 

"Schmidt" <sss@online.de> wrote in message 
news:eFUveQHcKHA.2596@TK2MSFTNGP04.phx.gbl...
>
> "mp" <nospam@Thanks.com> schrieb im Newsbeitrag
> news:OIWBz0DcKHA.1596@TK2MSFTNGP06.phx.gbl...
>
>> > First ensure, that you're using the latest Binaries and
>> > Demos from:
>> > www.thecommon.net/3.html
>> >
>>
>> thanks got em, will proceed with installs
>
> Ok, in that case the problem should remain a more
> or less theoretical one, since the newer SQLite-
> NWind-Demo-Application from the link above
> does not contain the ADODC-DemoForm anymore.
>
> I've also switched this new SQLite-Demo from the former
> dynamic Control-Loading to a normal, static one - to reduce
> such potential problems you just experienced with the
> older Demo-Code.
>
> Hope everything will work "right out of the box" now
> with the new (version3-related) Demo-Sources.
>
> Olaf
>

thanks Olaf, I'm sure I've done something wrong again!
I unzipped the new versions into my code projects path to a folder 
dhRichClient3
I copied the dhRichClient3.dll to an alternate location folder 
RegisteredDlls (siinglle location for common files so i keep track of where 
they are)
i try regsvr32 and point to the file and is says failed, module cant' be 
found!
checked and rechecked the path is right and the file is there!?!

> 

"mp" <nospam@Thanks.com> wrote in message 
news:eyfkJdJcKHA.1592@TK2MSFTNGP06.phx.gbl...
| thanks Olaf, I'm sure I've done something wrong again!
| I unzipped the new versions into my code projects path to a folder
| dhRichClient3
| I copied the dhRichClient3.dll to an alternate location folder
| RegisteredDlls (siinglle location for common files so i keep track of 
where
| they are)
| i try regsvr32 and point to the file and is says failed, module cant' be
| found!
| checked and rechecked the path is right and the file is there!?!

Just an FYI, if your path has actual spaces in it, you'll need to enclose it 
in quotes when using regsvr32 

"mp" <nospam@Thanks.com> wrote in message 
news:eyfkJdJcKHA.1592@TK2MSFTNGP06.phx.gbl...
> I copied the dhRichClient3.dll to an alternate location folder

That's one out of 3 files. See Readme.txt.

Hi,

mp schrieb:

> ...
> thanks Olaf, I'm sure I've done something wrong again!
> I unzipped the new versions into my code projects path to a folder 
> dhRichClient3
> I copied the dhRichClient3.dll to an alternate location folder 
> ...

The complete framework consists of three dlls:

- dhRichClient3.dll (a COM server dll)

You can put this dll in any folder you like and register it from there

- sqlitexxx.dll and directcom.dll (both standard dlls)

These dlls are used by the dhRichClient3.dll: it loads them. Therefore 
these dlls *must* be in a folder that is in the search path when the 
windows system is told to load these dlls. The windows system, when told 
to load a (standard) dll, searches for this dll in a variety of folders, 
starting with the folder the caller is in (the dhRichCLient3.dll), then, 
if not found, searching other folders, amongst them is the system folder.

So simply put the two standard dlls either into the same folder 
dhRichCLient3.dll is in or in your systems system folder or in any other 
folder that is in the system's dll search path.

Btw, the pathes used for search are noted in the environment variable 
PATH, separated by semicola.

-- 
Ulrich Korndoerfer

VB tips, helpers, solutions -> http://www.proSource.de/Downloads/

"Ulrich Korndoerfer" <ulrich_wants_nospam@prosource.de> wrote in message 
news:%23np9Q2JcKHA.1648@TK2MSFTNGP05.phx.gbl...
> Hi,
>
> mp schrieb:
>
>> ...
>> thanks Olaf, I'm sure I've done something wrong again!
>> I unzipped the new versions into my code projects path to a folder 
>> dhRichClient3
>> I copied the dhRichClient3.dll to an alternate location folder ...
>
> The complete framework consists of three dlls:
>
> - dhRichClient3.dll (a COM server dll)
>
> You can put this dll in any folder you like and register it from there
>
> - sqlitexxx.dll and directcom.dll (both standard dlls)
>
> These dlls are used by the dhRichClient3.dll: it loads them. Therefore 
> these dlls *must* be in a folder that is in the search path when the 
> windows system is told to load these dlls. The windows system, when told 
> to load a (standard) dll, searches for this dll in a variety of folders, 
> starting with the folder the caller is in (the dhRichCLient3.dll), then, 
> if not found, searching other folders, amongst them is the system folder.
>
> So simply put the two standard dlls either into the same folder 
> dhRichCLient3.dll is in or in your systems system folder or in any other 
> folder that is in the system's dll search path.
>
> Btw, the pathes used for search are noted in the environment variable 
> PATH, separated by semicola.
>
> -- 
> Ulrich Korndoerfer
>
> VB tips, helpers, solutions -> http://www.proSource.de/Downloads/

Thanks,
Thats what i was missing, he mentioned in the read me that they didn't need 
to be in system anymore so i left them where they were in the demo 
folder....I'd registered the client3 from my code folder as mentioned rather 
than a demo folder which would be just temporary home...didn't know about 
putting them in same location, thanks
mark 

"C. Kevin Provance" <*@*.*> wrote in message 
news:%23SkgomJcKHA.1648@TK2MSFTNGP05.phx.gbl...
> "mp" <nospam@Thanks.com> wrote in message
> news:eyfkJdJcKHA.1592@TK2MSFTNGP06.phx.gbl...
> | thanks Olaf, I'm sure I've done something wrong again!
> | I unzipped the new versions into my code projects path to a folder
> | dhRichClient3
> | I copied the dhRichClient3.dll to an alternate location folder
> | RegisteredDlls (siinglle location for common files so i keep track of
> where
> | they are)
> | i try regsvr32 and point to the file and is says failed, module cant' be
> | found!
> | checked and rechecked the path is right and the file is there!?!
>
> Just an FYI, if your path has actual spaces in it, you'll need to enclose 
> it
> in quotes when using regsvr32
>
>
i had tried with and without quotes(though I have no spaces)
apparently the non registered dlls need to be in same loc as client3.dll or 
in win/system32 as Ulrich pointed out.
thanks
mark

"Nobody" <nobody@nobody.com> wrote in message 
news:OSvcauJcKHA.2184@TK2MSFTNGP04.phx.gbl...
> "mp" <nospam@Thanks.com> wrote in message 
> news:eyfkJdJcKHA.1592@TK2MSFTNGP06.phx.gbl...
>> I copied the dhRichClient3.dll to an alternate location folder
>
> That's one out of 3 files. See Readme.txt.

right, but the other two aren't registered and I took the readme to say they 
could live in the demo folder just fine.
i should have read the modfactory.bas comments, there it explains they need 
to live together
thanks
mark 

"Ulrich Korndoerfer" <ulrich_wants_nospam@prosource.de> wrote in message 
news:%23np9Q2JcKHA.1648@TK2MSFTNGP05.phx.gbl...
> The windows system, when told to load a (standard) dll, searches for this 
> dll in a variety of folders, starting with the folder the caller is in 
> (the dhRichCLient3.dll), then, if not found, searching other folders, 
> amongst them is the system folder.

I am not sure it looks first in the caller DLL folder, but rather the EXE 
folder. See Remarks section of LoadLibrary() in MSDN Oct 2001, or this page 
online:

Dynamic-Link Library Search Order:
http://msdn.microsoft.com/en-us/library/ms682586(VS.85).aspx

Hi,

Nobody schrieb:

> "Ulrich Korndoerfer" <ulrich_wants_nospam@prosource.de> wrote in message 
> news:%23np9Q2JcKHA.1648@TK2MSFTNGP05.phx.gbl...
>> The windows system, when told to load a (standard) dll, searches for this 
>> dll in a variety of folders, starting with the folder the caller is in 
>> (the dhRichCLient3.dll), then, if not found, searching other folders, 
>> amongst them is the system folder.
> 
> I am not sure it looks first in the caller DLL folder, but rather the EXE 
> folder. See Remarks section of LoadLibrary() in MSDN Oct 2001, or this page 
> online:
> 
> Dynamic-Link Library Search Order:
> http://msdn.microsoft.com/en-us/library/ms682586(VS.85).aspx

Now this article does not explicitely state how the search order is for 
those dlls, that a dll (especially a registered COM server dll), that is 
loaded from an exe, loads.

I have often done this and it always worked for COM server dlls, that in 
turn depend on standard dlls:

- put the COM server dll and its dependend standard dlls in the same 
folder (may be any folder, including being not the applications folder) 
and register the COM server dll in this folder

The dependend dlls always are found. I did not *test* wether the system 
looks *first* in the Com server dlls folder. But this (deducing this by 
applying some logic thinking) must be so, because non of the standard 
folders (system, windows, current) points to the dependend dlls, so the 
only folder remaining is the one MS refers to be the application folder, 
but in my oppinion should be noted as the COM servers folder. I trust 
the MS documentation in that the application folder is the first one to 
be searched, and, deducing, meaning the Com servers folder.

-- 
Ulrich Korndoerfer

VB tips, helpers, solutions -> http://www.proSource.de/Downloads/