ReportPro 3.9 and sql table swap

[gjbiagiotti]

Hello everyone.
I use VO 2.8, Report Pro 3.9 (Active X) and PostgreSQL. The problem I have is when creating a report with auxiliary tables, then in execution I change the name of the report table and when executing the command:
SELF: oReport: PreviewReport ()
An error message appears: Subsystem Error: 00000
The code is the following:
SELF: oReport: = IRpRuntime {"ReportPro.Runtime.39"}
SELF: oReport: LoadReport (cReporte)
SELF: oReport: SetConnection (CONNECTION_ODBC, oGvar: cDriverSQL, 1, 1)
SELF: oReport: SetTableStringAttribute (1, TableAux, SQLTABLE_ATTR_TABLE, TableNew)
SELF: oReport: Connect2Source ()
SELF: oReport: PreviewReport ()
SELF: oReport: Close ()
SELF: oReport: Destroy ()
SELF: oReport: = NULL_OBJECT

But if I use the same table name with which the report was created, it works fine.
Does anyone know what the problem may be?
Thanks a lot.

Gerard of Argentine

[gjbiagiotti]

Hello
I also tried changing this line:
SELF: oReport: SetTableStringAttribute (1, TableAux, SQLTABLE_ATTR_TABLE, TableNew)
for this:
SELF: oReport: SetTableStringAttribute (1, "DSN", SQLQUERY_ATTR_SQL_FROM, "TableAux as TableNew") // From.

and it keeps giving the same error: Subsystem Error: 00000
What I could see is that the problem is caused by changing the table with which the report was designed.
Has anyone had this problem with Report Pro 3.9?

[TimothyS]

Hi.

I'm assuming you are using the DotNet RP3.
The function :
FUNCTION RP3SQLCALLBACK(nMode, uParam)

Should be able to do the trick. Docs are in the listofchanges.txt file. It may not be so straightforward with the VO version.

Regards,
Tim

[gjbiagiotti]

From what I have been able to see it is a bugs of Report Pro 3.9 in the version for VO 2.8
It is rare that no one has reported it.
Gerardo

[gjbiagiotti]

Hello. I use the IRpRuntime{} class that I have generated through the VO Automation Server.
Would you have an example of VO code of how you send the tables to the report in execution mode?
Thanks.
Gerard

[Jamal]

Hello Gerard,

I don't use ReportPro with SQL, but the following may trigger some thoughts on your end

I think it is a good idea to check if the connection is the connection is successful first before calling other methods,

i.e.

Code: Select all

  If SELF: oReport: SetConnection (CONNECTION_ODBC, oGvar: cDriverSQL, 1, 1)
     // your code
  else
     // display error message
  endif

Also, what is 1 for handle1 and handle2 in the SetConnection(...) method parameters? Shouldn't you be passing SQLConnection:EnvHandle from an already established connection using the VO SQlConnection class?

HTH,
Jamal

[gjbiagiotti]

Hi Jamal.
The problem is that the SQLConnection:EnvHandle and the SQLConnection:ConnHandle return non-numeric values.
They return 0x02233270 and 0x022332F0, respectively.
Gerard

[Jamal]

Hi Gerard,

Those are PTR values. The VO documentation is wrong to say EnvHandle is of LONG data type.

Internally the SQL class has a hidden variable:

Code: Select all

 HIDDEN hEnv           AS PTR

and declares:

Code: Select all

ACCESS EnvHandle CLASS SQLConnection

   RETURN hEnv

I suggest you declare:

Code: Select all

LOCAL pSqlRet AS PTR

// connect to to SQL....

// then 
pSqlRet := oYourSqlConnection:EnvHandle 

then pass it to ReportPro:

Code: Select all

If SELF: oReport: SetConnection (CONNECTION_ODBC, oGvar: cDriverSQL, pSqlRet  , pSqlRet )
     // your code
  else
     // display error message
  endif

HTH,
Jamal

[gjbiagiotti]

Hello jamal

In this code that you suggest, the variable pSqlRet is still of type PTR, and returns a value of the same type, but the SetConnection order of the Report needs a value of type numeric.

Gerard

[Jamal]

You can convert to a LONG and see how it goes.

LONG(pSqlRet)

Jamal