X# Report asks for missing DBF which is clearly present

[ic2]

We have a weird ReportPro (VO 2.31) problem for which I give multiple details in case they are related. From the X# program (using ReportPro 2.40) the program asks for a missing dbf which is not missing. Besides, that (long unchanged) report now shows much delayed from the VO based program.

What happens:

1 A specific report now takes 12 seconds to show from the (VO) program (on Connect2Source) instead of immediately (from VO). But then it works. It has always worked immediately

2 From an X# program, the program asks for 1 specific dbf it says is missing (including 1 cdx) which is present and seems ok. The reports runs from f:\MyDBFDir\RPT and shows the missing file with that subdirectory (instead of the datadirectory f:\MyDBFDir)

3 If we manually point to the correct (and programmed and working) dbf in f:\MyDBFDir the program continues asking if we should use another databasedriver

4 The swap array is filled in the program, correctly. If we instantiate a new local dbserver variable there and assign the same dbf (f:\MyDBFDir\MyDBF.dbf) the program still asks for that dbf for any time used (again in the dir of the report f:\MyDBFDir\RPT) but if we point now to that same file the report eventually shows

5 Other reports using the same DBF (also in the same path) do not show a delay or issues and also work from the X# program without asking for that dbf. So that should rule out a damaged DBF or CDX

6 The system uses ADS Server

7 When run the X# program and report locally on the development Pc using c:\testdir as datapath, it all works without delay or asking for the DBF

Is there any logic in the above behaviour so we know what we should fix?

Dick

[robert]

Dick,
We will need the report and its files and the exact configuration on the machine (path of the exe, path of the report and path of the dbf files, X# version etc) where the problem is occurring.

Robert

[ic2]

Frank found an unusual way to solve the direct issue. He found out that the dbf was only reported missing for instances after the first in the section tree. He solved it by changing:

Code: Select all

AAdd(aSwap, {"Laadlos3",,,,,	oDBLaadlos})

to

Code: Select all

		AAdd(aSwap, {"Laadlos3",,,,,	oDBLaadlos})
		AAdd(aSwap, {"Laadlos31",,,,,	oDBLaadlos})
		AAdd(aSwap, {"Laadlos32",,,,,	oDBLaadlos})
		AAdd(aSwap, {"Laadlos33",,,,,	oDBLaadlos})

(using the internally used names in the sections).
Not sure why it worked but I think you should not need to check the report then.

Thanks!

Dick

[robert]

Dick,
If the same table is used in different sections with different aliases, then the solution where you're setting it for each of the aliases is the expected solution.
Robert

[ic2]

Thanks Robert.

Two curiosities remain: Do you have an idea why it worked without this extra 'swaps' from the VO based program? And that it didn't fail from the local (Development) directory either using the X# based program?

What remains a problem is that (since a while, from the VO based program) Connect2Source() takes 12 seconds to complete where it was <1 second.
How could we find out what it is doing what it didn't do before?

Dick