Dictionaries and Out of Memory error....

I have not run across this problem, though here are a couple of links with info that might be of assistance:

http://support.crystaldecisions.com/library/kbase/articles/c2009321.asp

http://support.crystaldecisions.com/communityCS/TechnicalPapers/cr_memoryfull.pdf.asp

Hope this helps.

WHat code are you using to view the report?

Is your code used to generate the dictionary or is it only CR?

mlmcc

Thanks dbirdman... will take a look at those articles and let you know how it goes.

mlmcc, the code I'm using is....

Private Sub ShowReport()

Dim objDatabase As CRAXDDRT.Database
Dim objEngine As New CRAXDDRT.Application
Dim objReportObject As Object
Dim objSection As CRAXDDRT.Section
Dim objSubReport As CRAXDDRT.Report
Dim objSubReportObj As CRAXDDRT.SubreportObject
Dim objTable As CRAXDDRT.DatabaseTable

    Set mobjReport = objEngine.OpenReport(mstrReport)

' Are we re-directing to a different datasource?
    If mblnRedirect= True Then
        ' Get the database for this report
        Set objDatabase = mobjReport.Database
       
        ' Log onto the server
        objDatabase.LogOnServer "pdsodbc.dll", mstrDataSource, mstrDataSource, "root"

        ' Redirect to the correct dataset
        For Each objTable In objDatabase.Tables
            Call objTable.SetLogOnInfo(mstrDataSource, mstrDataSource, "root")
            If objTable.TestConnectivity = False Then
                MsgBox "An error occured while setting the data source for this report.  Please confirm that the linkage between company and data source is correct.  (Tools/Options/Data Sources)", vbOKOnly + vbExclamation, Me.Caption
                Exit Sub
            End If
        Next objTable
       
        ' Loop through the report sections
        For Each objSection In mobjReport.Sections
            ' Loop through the section objects
            For Each objReportObject In objSection.ReportObjects
                ' Check the type
                If objReportObject.Kind = crSubreportObject Then
                    ' Get hold of the report
                    Set objSubReportObj = objReportObject
                   
                    ' Open the report
                    Set objSubReport = objSubReportObj.OpenSubreport
                   
                    ' Get the database for this report
                    Set objDatabase = objSubReport.Database
                   
                    ' Loop through the tables
                    For Each objTable In objDatabase.Tables
                        Call objTable.SetLogOnInfo(mstrDataSource)
                    Next objTable
                End If
            Next objReportObject
        Next objSection
    End If

    mobjReport.DiscardSavedData

    crvViewer.ReportSource = mobjReport
    crvViewer.ViewReport

End Sub

Thanks!

I believe that with this line of code

       objDatabase.LogOnServer "pdsodbc.dll", mstrDataSource, mstrDataSource, "root"


you are telling CR to use the 16 bit ODBC drivers.  You might want to use "p2sodbc.dll" instead.

DRRYAN3

You're right DRRYAN3.

mlmcc

Thanx DRRYAN3 and mlmcc, I've made that change, but I'm still getting the out of memory error if the .dc5 file is in the place that the .rpt expects it to be.

Any more idea's?

Sorry!

Not sure if this will help, but....

While I was stepping through the code I put a watch on the objTable object when it was about to do the objTable.TestConnectivity line.  The line failed sometimes when it succeded properties such as Location were populated.  When it failed the object reported that Location was "Not Supported", along with a couple of other properties that had been previously populated.  Also, the property that holds the DLL name was empty.

Thanx,

Julian

Try using CRAXDRT instead of CRAXDDRT when declaring your variables.  CRAXDDRT requires a royalty payment when distributed.

At what line in the code you've provided do you get the out of memory error?  Is it when you call the view method, or is it before that point?

DRRYAN3, I've changed over to CRAXDRT - I didn't realise it had royalty payments required - thanks!

The error occurs when I do the...
If objTable.TestConnectivity = False then

... line, but if I allow it to carry on beyond that point it errors when I do the...
crvViewer.ViewReport

I'd bet that the problem is in the

Call objTable.SetLogOnInfo(mstrDataSource, mstrDataSource, "root")

line of code.  What is your backend database?  What does your mstrDataSource string look like?  Did you use the ODBC drivers when you designed your report, or did you use the Crystal drivers native to your database?

DRRYAN3

mstrDataSource holds the name of an ODBC DSN, and the one I used was called "bb live.udd".  The same one was used on the design machine as was used on the viewer machine.

That DSN uses a Transoft driver for C-ISAM files residing on a Unix server.

Hope that helps!

Thanks,

Julian

Do you have any problems using this arrangement with ordinary ADO recordsets which are similar to what you are trying to pull into your report?  Still sounds like a database connectivity issue to me.

I've never tried using the viewer with an ADO recordset, just this ODBC driver.  If it's a connectivity issue how come the report always works in Crystal Designer, using the same Crystal Dictionary and ODBC driver?  Is the syntax I'm using to connect in the viewer wrong?

Here is the code I use to accomplish a data source switch:

dim crRept as CRAXDRT.REPORT
dim crDBTab as CRAXDRT.DATABASETABLE

set crRept = crApp.OpenReport("whatever.rpt")
crRept.Database.Logonserver "p2ssql.dll", "SERVERNAME","DBNAME", "USERID", "PASSWORD"
for each crDBTab in crRept.database.tables
  crDBTab.setlogoninfo "SERVERNAME","DBNAME","USERID","PASSWORD"
next

This code works 100% of the time for me with MS SQL OLEDB drivers and I switch on the fly to about 6 different servers.  The only difference I see between this code and yours are that you appear to have the server and database name set to the same value.

When I asked about the ADO recordset, I was wondering if you were able to setup a recordset and step through it in code, not in the report.

I've assumed so far that you have compared the DLL versions on the development and production machines.  Are they the same?  Are there duplicates in different directories?

DRRYAN3

Quoting from the online guide for 8.5...

"Dictionaries simply provide all of the convenience with the restrictions." and "... dictionaries are optional components.  Data can still be access directly by the user."

After re-reading your problem statement, I think you may have misunderstood the point of the Crystal Dictionaries.  When you use them, you are basically locking the report into whatever data source and set of fields the dictionary designer has decided you should see.  You cannot use the dictionary with another data source, for example.

It appears you are distributing your report(s) as part of an application.  In this case, why the dictionaries?  Just go to the ODBC data source and do the reporting.  Your technique is correct if you omit the dictionary.  There is not an API that I can find, however, for modifying the dictionary from code, which will prohibit you from being able to access alternate data sources on the fly while using a dictionary.

DRRYAN3

Are you coming back?

JulianDavies

I ask again, are you coming back?  Have you made any progress?  Do you disagree with my last comment or did it not help?

DRRYAN3

Sorry for the delay in replying.

My understanding was that the dictionary allowed you to make life easier for the report designer by giving them a set of tables with helpful field names (aliases) and ready-linked... a sort of data map.   Once compiled I believed that this map was stored (in some form) in the report itself with a reference to the dictionary that helped generate it.  (Not sure if I've explained myself too well there, but that's how it seems to me)

So coming back to what you said, yes, I know the designer can get straight to the underlying data and by-pass the dictionary, but it's not in their interest to do so due to the complexity of the full data-set (and hence we produce a simplified sub-set in a dictionary).  But I disagree that using a dictionary locks the report completely because that same report, when the dictionary is not available, can still work and can be re-directed to a different datasource - I've already done that bit!!

Back to my problem, I know I can't do anything to the dictionary at run-time (nor do I need to), but if the dictionary file is just present the viewer fails to load the report if I change the reports datasource by the normal methods.  That is what I want to over-come, it seems to me that if the dictionary is present the report interacts with it some how and a side-effect of that interaction is the problem I'm experiencing.

Does any of that help, sorry it's a bit waffly,

Thanks,

Julian

Well, that explains what's going on!  Thanks for all your help DRRYAN3.... u definitely deserve the points.

Cheers,

Julian

Glad to help