Installing app with DataReport

I wonder if anyone could shed some light on a problem I'm having on some (not all) PCs where I've installed an app with a DataReport. The app itself works fine, until I try to instantiate the DataReport, at which point I get "Runtime error '429': ActiveX component can't create object."

I got this working on some computers by working through some of the fixes from MSDN for P&DW bugs related to the DataReport (specifically, I added MSDERUN.DLL and related files to the .cab and changed the registration properties of the .tlb files). But I'm still getting the error on some systems.

I developed the app on a Win98 machine. I've gotten it to work on Win95 machines where Office is installed, but not those without it. I'm sure that isn't the only common denominator, and I have no idea whether it's even relevant, but obviously *something* is missing. Thanks for any suggestions.

Include these files with your app. All the installers I've used seem to miss one or more of these for some reason. I don't even know why they're all required, but I always seem to have the same problem you describe if I don't include them.

msdbrpt.dll
msdbrpt.srg
msdbrptr.dep
msdbrptr.dll

Well, Reboot, I was really hoping that would fix it, since some of those files were missing from the .cab file. Unfortunately, I still get the same error after adding them. :(

Any other suggestions?

Here is an extremely unlikely thing you can check. Open up the
references dialog and look for Microsoft Data Report Designer 6.0.
There are actually two of them. Make sure the one checked is
msdbrptr.dll and not msdbrpt.dll. Like I said, very unlikely, but
can't hurt to check.

Good thought, Thinker; I hadn't realized there were 2. I do have the msdbrptr.dll one checked, though.

Still stumped...

Well, I feel kinda dumb now. :-\ After adding a bit of logging, it turns out that the error is actually occuring before I do anything with the datareport itself; it's related to the ADO hierarchical recordset I'm using. I'll dig a bit deeper there, but in the meantime, do you know of any obvious pitfalls that might be causing that error with ADO objects?

The error is occurring when creating a new connection object:
Set oConn = NEW ADODB.Connection

Are you including mdac_typ.exe with the install? What version?
On win95 computers, it might also be necessary to include DCOM95.

You're right, Thinker, I did need to install DCOM (just figured that out a minute ago). Now I get a different error: "Runtime error '430': Class does not support Automation or does not support expected interface" at this line:
Set HRSet = New ADODB.Recordset

I am including mdac_typ.exe; the version showing is 2.50.4403.12.

That would be version 2.5 (which would include the necessary
jet OLEDB provider.) But, did you by any chance reference a
higher version in the project (like 2.6 or 2.7)? If so, maybe you
could just change the reference to 2.5, recompile and try the new
exe.

No, 2.5 is the one I referenced in the project. :confused:

Ok, now I am really reaching. How is HRSet declared?
Dim HRSet As Recordset
or
Dim HRSet As ADODB.Recordset
If not the second one, then try that.

It's a parameter to the procedure, not a local variable, but it is already defined the latter way:
Private Sub GeneratePNRecordset(ByRef HRSet As ADODB.Recordset)

This is a bit confusing now. Are you passing in a instantiated
recordset and then trying to replace it with a new object, or just
passing a reference to a 'Nothing' object variable? If the idea is
to pass back an instantiated and opened recordset, wouldn't it be
better to say...

Private Function GeneratePNRecordset() As ADODB.Recordset
Dim HRSet As ADODB.Recordset
Set HRSet = New ADODB.Recordset
...
Set GeneratePNRecordset = HRSet
End Function

That's what I was just asking myself after I posted that last message! I have no idea why I did it that way, but I've rewritten it now (and my new code looks amazingly like what you suggested :-\)...

I wouldn't think that would have any bearing on that error, though, would it?

I wondered if it could have an effect if the variable already contained
an instantiated recordset object.

One other question, what service pack are you on with VB6?

SP5.

There just aren't too many other things it could be.
Did it make any difference changing the sub to function and
returning a recordset object?

Well, I made that change, & I also removed & re-added the reference to the ADO 2.5 library, took the files back out that Reboot had suggested above (except for msdbrptr.dll, of course, which was there originally), and repackaged the project yet again. And one of those changes fixed it!!

Thank you so very much for all your help, Thinker! You're awesome. ('Course I knew that, even if you hadn't helped me solve this! ;))

I'm really glad to hear that something worked. I was out of ideas. :)