cancel
Showing results for 
Search instead for 
Did you mean: 

ApplyLogonInfo Reverts all Properties (SP5 regression?)

ido_millet
Active Contributor
0 Kudos

Crystal for VS 2010 SP5, vb.net, winform.

I am changing the ODBC DSN in code that worked in SP4 but now is failing.
Tracing the table properties in debug mode shows that the table properties change as expected after this line:

TableN.LogOnInfo.ConnectionInfo = My_ConnectionInfo

But after calling the next line:

TableN.ApplyLogOnInfo(TableN.LogOnInfo)

All properties immediately revert to their original values, as shown in the picture below.  Is this a known regression?

There are prior posts about this problem in past threads and on the web. For example:
http://scn.sap.com/thread/3201919
http://scn.sap.com/thread/1096512

After calling ApplyLogOnInfo, all properties revert to their original values:

Note: some past threads suggest building the Connection Properties collections completely from scratch. I can't pursue that strategy because my application can be used by different users for different types of ODBC connections. It seems reasonable to assume that we should be able to simply change the ODBC DSN without going through a process of recreating all connection properties.  Or am I too optimistic...

Accepted Solutions (1)

Accepted Solutions (1)

ido_millet
Active Contributor
0 Kudos

More info: while the properties indeed revert back to their original values, it looks like this doesn't stop at least some reports from connecting to the newly specified DSN.

It is still not clear to me why the connection properties of the table revert back to their original values upon a call to ApplyLogonInfo().  Could someone offer a detailed explanation of how ApplyLogonIOnfo() operates and why it immediately causes a reset of all connection attributes to their original values (at least when monitored via a debug session)?

What causes an apparent difference between the properties shown for the Table object in a debug session within the IDE and the actual behavior of the table during that same debug session. For example, why is it that after the DSN and server properties revert back to DSN_Original upon a call to ApplyLogonInfo(), yet the table still connects to DSN_New?

Note: this is not because of multiple tables whereby the first table already connected to DSN_New -- I tested this with a single table scenario.  ODBC connection to SQL Server.

0 Kudos

Hi Ido,

Interesting that some work. Have a look at the report properties, are any of the Verify database options checked on? May explain why some work.

Think of your DSN as a datasource, you change your database and CR needs to verify the change, you change your DSN and CR needs to verify the change. If you don't specifically call the Verify option then the engine may or may not verify, not sure what the exact triggers are. Odd that the Debug UI sometimes shows the old info but uses the new info....

If you need to change DSN's then use RAS and ReplaceConnection method. The app attached to this kbase will generate the code for you and you can get the info dynamically, you don't have to do it manually:

1553921 - Is there a utility that would help in writing database logon code?

In your existing code are you calling Verify Database at all? If not does that resolve the issue? May explain also why the values show old info, the trigger that updates the values in the Old/New collection may be out of sink.

Use CRLogger to see what the engine is actually sending to the Server:


1553469 - How to enable Database logging in Crystal Reports for Visual Studio 2010

As for why it worked in SP 4 and not 5 possibly there was an issue that was fixed or possibly it is a new issue that was introduced in SP 5.

The second post has nothing to do with this version. The first post seems to be the same as your findings maybe

Don

ido_millet
Active Contributor
0 Kudos

Hi Don,

You say above "May explain also why the values show old info", but the images above are not about info in the database, they are about Connection Properties for the table. 


Key Question: Is it an expected behavior that calling ApplyLogonInfo() immediately resets all connection properties to the original properties of the table? 

Background: By immediately I mean there is no intervening code. You call ApplyLogonInfo() and if you stop on the next line of code, you can see that all the newly assigned properties have reverted to their original values.

I suspect this is a bug that is somehow related to the fact that this line:
TableN.LogOnInfo.ConnectionInfo = My_ConnectionInfo

is using a connection object that was not created from scratch. Instead, it was copied from the connection info in the report, and then properties of that object were changed.

The next line:
TableN.ApplyLogOnInfo(TableN.LogOnInfo)

somehow fails to "behave" at that point due to some internal circular references? 


Shouldn't developers be able to change a connection property for a table without recreating a connection object from scratch?

Thanks!

- Ido

0 Kudos

What DB driver are you using in your DSN and what DB is it connecting to?

What does the properties on the Designer show, are they the same as what you are using in code?

CR dynamically reads the DSN info and the Driver ( DB Client dll ) is used to determine what the SQL CR needs to generate, could be your DB client dll changed or the driver is not what the report expects to use.

Are you changing DB Server types, example is MS SQL to Oracle also?

Not enough info to go on.

ido_millet
Active Contributor
0 Kudos

Driver is ODBC SQL Server (SQLSRV32.dll) connection.
Properties in Designer:
Database Type: ODBC (RDO)
Data Source Name: warehouse  (I try to change this to warehouse_renamed)

User ID: ixm7

Database: student

Use DSN Default Properties: False  (same behavior when this is set to True)

This is a Single Table scenario.  I am not changing drivers, table names, database names, etc.  -- just the DSN.

Sorry for repeating the same question: is it expected that under any scenario, the call to SetLogonInfo() would cause changed connection properties (DSN and Server in my case) to immediately revert to their original values?  This would tell me if the behavior I'm seeing is normal or abnormal.


0 Kudos

Yes it's normal, CR reads the ODBC.INI from the registry and copies it into the report, if there are changes to the DSN/Registry then CR needs this verified. CR assumes once the various connections are made they don't change. If changes are made to either or both then you must use RAS to update the report connection properties.

Could be the drivers, what version of MS SQL is it? That is the old MDAC driver.

MS doesn't full support MDAC connecting to the newer servers and CR for VS prefers using the new Native Drivers 10 or 11 driver.

http://msdn.microsoft.com/en-us/library/ms131035(v=sql.110).aspx

You could try using the SQL Native Client if it's SQL 2005 or older, sqlncli.dll, that may work for you.

And if this may be related also, try checking on the Verify Database in the report, just as a test. More info below as to why I'm asking you to do this.

I'll ping the developers to see if they changed anything regarding ODBC Connection properties. They have done a few updates in the connection methods around parameters and Stored Procedures and the parameter name index, it may be related to this now that I think of it, there was a disconnect between the 2 collections that caused the Parameter indexes to be out of sync.

This bug that was introduced in SP 2 and fixed in SP 5 may have caused this disconnect in the log on info.... not good... Problem is can't dup with a new report right now so it could be RPT version related also....

Can you add this to a message box and test that report?

MessageBox.Show = rptClientDoc.MajorVersion.ToString() + "." + rptClientDoc.MinorVersion.ToString();

I'm curious what version of the RPT this is.

Don

0 Kudos

Oh and more important...

Are you using or have you ever used the rpt.database.table.location method to set that part of the database info? Or are you assuming CR will just update the info using the log on method?

Would look something like this:

crTable.Location = crDatabase + ".dbo." + crTable.Location;

Don

ido_millet
Active Contributor
0 Kudos

Hi Don,

The report version comes back as 8.0

In the scenario I'm testing there is no Table.Location calls.

When you say, "yes it's normal" above are you referring to the behavior whereby a call to SetLogonInfo() causes all connection properties to revert to their original values?  If so, why? Should we expect it to ALWAYS have that effect?  If not, under what scenarios should we expect that effect?

Thanks for pursuing this!

0 Kudos

Hi Ido,

Version 8.0 is the problem. As you know as of CR 9 we renamed all of the DB driver dll's so it's the mapping ( CR import routine on open ) of those old dll's to the new dll's that is likely why this works sometimes. Also, when we updated the drivers we removed all of the "hacks" we had to do to put into our drivers to get past issues the DB clients had. We are now ANSII 92 compliant ( ODBC ) and other native standard compliant. If there is an issue it's not something we fix for them, they have to fix the bugs. We dynamically query the DB clients to get a list of functionality they support and generate the SQL accordingly. Which is why if you enable CRlogger ( DB logging ) you'll see line where we query the Driver and a message will come back from the client "not supported" or something like that. ODB Trace logs will show you this also.

Update the report manually to CR 2008 or above and then test again, I believe you'll find it works as it used to. Use the Set Table location to update the report also and then Verify the Report. Now save it and test.

Likely due to the open/import routines CR uses to update old reports to current rpt format and drivers references. This one issue may have been missed. No option now to escalate but if you want to provide the info I may be able to get Developers to look into it.

Don

ido_millet
Active Contributor
0 Kudos

Thanks, Don!  I didn't get email alerts about your latest posts, so I didn't realize you posted new info.

It may indeed be a report/driver version issue because an ODBC trace shows:
DIAG [IM006] [Microsoft][ODBC Driver Manager] Driver's SQLSetConnectAttr failed (0)

The ODBC trace also shows that the process is using the new DSN even though the Table connection properties reverted to the old DSN upon the call to the mysterious ApplyLogonInfo().  It would be great if you could find an explanation for that behavior or for what ApplyLogonInfo() actually does (particularly when it is set to its own changed properties).

ido_millet
Active Contributor
0 Kudos

Don,
I bet the issue is the old rpt version. So I'm marking this thread as solved.


Many thanks!

- Ido

Answers (0)