Bad labels

[jrizzo]

With the attached LayerDefinition?, the labels look incorrect at certain scales. Zoomed all the way out or zoomed in really close, the labels look fine. Some scales (135 for example) show the labels as long numbers (pointer addresses, possibly?). An example of a bad label & a good label along with the sample data set will be attached. The feature source is an SDF feature source joined with an ODBC feature source (a SQL Server view). The ODBC feature source has been omited for security purposes. The labels contain values from the extended properties. This was working fine in 1.1.

[jrizzo]

This is one of the "bad" labels

[jrizzo]

This is what the "bad" label is supposed to look like.

[jrizzo]

This package contains the layer definition & sdf feature source

[tomfukushima]

I cannot get the attached package to work because of the dependency on the joined data. Please attach a package that works and shows the problem. Thanks.

[jrizzo]

Here is the feature source definition with the username & password removed. You can modify the connection string as necessary for your testing

[jrizzo]

Here is the config xml stream from the database feature source. This should contain enough information for you to reconstruct the view in your testing environment.

[jrizzo]

I have updated two files that should help - the feature source definition and the corresponding config.xml. It may be quite a bit more difficult to post the actual database view that I am using...?

[tomfukushima]

Hi,

What I am looking for is the ability to load a package and then see the problem. Unfortunately, I don't have the resources to try to recreate the problem. Trying to recreate the problem has the issue of: we won't know for sure when to stop if we cannot recreate the problem. With this in mind, please help us by creating a self-contained package that we can load and show the problem.

I know that this is not always easy, but your help is greatly appreciated.

Thanks Tom

[tomfukushima]

Just as a further note, I'm not expecting the SQL Server to be attached, but perhaps it may be possible to take a sample out of the SQL Server and put it into an Access database, and recreate it that way.

[jrizzo]

This package should demonstrate the problem at a display scale of 1:100

[jrizzo]

I have uploaded a package which should reproduce the defect using an Access database. Please let me know if I can provide additional information. Incidentally, the Access version of this layer is considerably faster than the SQL Server version that I am currently building. In Access, it is lightning fast, and in SQL Server it is almost unuseable. I think (hope) this performance difference is already logged as a defect but I am not sure.

[chrisclaydon]

Would you be able to attach the Access database file you're using? If that poses a security problem, perhaps you could create a small mdb file with some fictitious data that can be used to reproduce the problem.

Thanks, Chris.

[jrizzo]

The access database

[jrizzo]

Sorry, I assumed that it would have been included in the package, but I guess I wasn't thinking. I just uploaded the file. Thanks.

[rexszeto]

Hi, I've been trying to reproduce this, but have been unsuccessful so far. The SDF and Layerdef from the package came with some invalid data (mainly caused by the join fields). I've tried adjusting the values and the preview in layer def showed the labels are working fine.

Can you please make the correct changes to the package so we are able to load the package and see the problem?

Some problems I've come across: - The SDF feature source gives an error "Resource was not found:  Library://Langan Floor Plans/Data/Database/Floor? Plan Database.FeatureSource?". I fixed this by changing the source field for the Room Join.

- The secondary class for 'Room\' is not specified due to the incorrect source (from above). I re-directed it to the correct database ( Library://Defect/Floor Plan Database.FeatureSource?) and chose "Default:Floor" as the secondary class.

- The columns to match the table + secondary class are missing from both Employee\ and Room\. For both joins, I matched up the FloorIds?.

- The layer definition was not able to find the feature source, (Due to point 1, see above). I correct it by directing it to a working feature source, but however, the feature class and labels were all set to default. This was where I tried defining the labels for the "Schema1:Office Data" class and they all show up fine.

If there's anything else missing, please include it in the new mgp.

Thanks, Rex.

[jrizzo]

Updated package

[jrizzo]

apologies for the ties to my live data. I have uploaded an updated package with these dependencies removed - the only change that should be necessary on your end is to modify the database connection string with the correct path to the .mdb

With the latest version, I tried reproducing the issue by zooming to exactly 1:100 and the problem does not seem to happen at that scale. however, after panning and zooming in and out a little bit, the labels eventually go bad. I can't find an exact location or scale that causes it, but it usually only takes a few seconds of navigating around for the labels to go bad.

[jrizzo]

Was this behavior ever reproduced, or do you need something more from me?

[rexszeto]

This important issue have been reproduced and will be addressed. Apologies for the delay.

[jbirch]

Hey jrizzo, have you had a chance to test this with the 2.0 RC4 build yet? There have been many fixes to the join code that may have affected this.