java import vs manual import
23 April, 2013
Hi,
We're having some issues importing views using the java importer.
When we use the importer the views are not always overwriting existing views. When this happens, we are getting logged output as in the attached bc_upgrade.log file. The end result of this was that a second view was created with the same name as the first view.
To investigate what was happening, I tried a manual import via the Admin Import screen and successfully overwrote the existing view, with no error or warnings on screen. There doesn't appear to be anything in the yellowfin.log file for this import - should there be?
Following that successful manual import, we tried the java import again. This time it was successful and gave the log file bc_upgrade.log-2
The command used in the java import was:
[code]
java $JAVA_OPTS -cp "$CLASSPATH" com.hof.standalone.ImportData /u/shells/intranet/module/magiqbi/ootb/upgrade.properties './Building Consents.xml' 2>&1
[/code]
The upgrade.properties file is available, but as it contains password/login detail I'd rather not post it here - I can email it if required.
So, what we need to know is why the java import fails, or at least doesn't overwrite the existing view, while the manual import/replace does work.
Thanks
Brendon
We're having some issues importing views using the java importer.
When we use the importer the views are not always overwriting existing views. When this happens, we are getting logged output as in the attached bc_upgrade.log file. The end result of this was that a second view was created with the same name as the first view.
To investigate what was happening, I tried a manual import via the Admin Import screen and successfully overwrote the existing view, with no error or warnings on screen. There doesn't appear to be anything in the yellowfin.log file for this import - should there be?
Following that successful manual import, we tried the java import again. This time it was successful and gave the log file bc_upgrade.log-2
The command used in the java import was:
[code]
java $JAVA_OPTS -cp "$CLASSPATH" com.hof.standalone.ImportData /u/shells/intranet/module/magiqbi/ootb/upgrade.properties './Building Consents.xml' 2>&1
[/code]
The upgrade.properties file is available, but as it contains password/login detail I'd rather not post it here - I can email it if required.
So, what we need to know is why the java import fails, or at least doesn't overwrite the existing view, while the manual import/replace does work.
Thanks
Brendon
I've also been asked if the fact that all our created views seem to have 'New View' as a view name could have something to do with it:
[code]
mysql> select * from ReportView ViewDescription = 'Projects'G;
*************************** 1. row ***************************
ViewId: 197937
ViewName: New View
ViewDescription: Projects
ViewStatusCode: OPEN
DefaultFilterCode: NULL
SourceId: 28004
AccessCode: UNSECURE
ViewTypeCode: DRAGANDDROP
SQLText: NULL
BusinessDescription: Projects Description
TechnicalDescription:
IpApprover: 0
CreationDate: 2013-04-23
IpCreator: 10305
IpLastModifier: 10305
LastModifiedGMTDateTime: 20130423235531
LastModifiedDate: 2013-04-23
LastModifiedTime: 86131
ParentViewId: 0
TimeDimensionRequiredCode: NULL
DefaultCachePeriod: 0
QuerySequence: 0
QuerySequenceType: NULL
TableSize: 0
IpTester: 0
ImpactTestDateTime: 0
ImpactTestCode: NULL
ApprovedDateTime: 0
SQLDocumentId: 0
OriginalViewId: 0
VersionNumber: 0
Audience:
ChangeDesc: NULL
TestSQLDateTime: 0
TestSQLCode: NULL
DisplayProperties: NULL
ViewRowLimit: 0
CategoryCode: NCSVIEWS
ResultBuildCode: OPTIMISE
ResultUpdateCode: NULL
PublishUUID: cb327e7c-964a-4e7e-893e-fac43d57a604
TranslationTimestamp: NULL
TranslationStatusCode: NONE
1 row in set (0.01 sec)
[/code]
Thanks
Brendon
[code]
mysql> select * from ReportView ViewDescription = 'Projects'G;
*************************** 1. row ***************************
ViewId: 197937
ViewName: New View
ViewDescription: Projects
ViewStatusCode: OPEN
DefaultFilterCode: NULL
SourceId: 28004
AccessCode: UNSECURE
ViewTypeCode: DRAGANDDROP
SQLText: NULL
BusinessDescription: Projects Description
TechnicalDescription:
IpApprover: 0
CreationDate: 2013-04-23
IpCreator: 10305
IpLastModifier: 10305
LastModifiedGMTDateTime: 20130423235531
LastModifiedDate: 2013-04-23
LastModifiedTime: 86131
ParentViewId: 0
TimeDimensionRequiredCode: NULL
DefaultCachePeriod: 0
QuerySequence: 0
QuerySequenceType: NULL
TableSize: 0
IpTester: 0
ImpactTestDateTime: 0
ImpactTestCode: NULL
ApprovedDateTime: 0
SQLDocumentId: 0
OriginalViewId: 0
VersionNumber: 0
Audience:
ChangeDesc: NULL
TestSQLDateTime: 0
TestSQLCode: NULL
DisplayProperties: NULL
ViewRowLimit: 0
CategoryCode: NCSVIEWS
ResultBuildCode: OPTIMISE
ResultUpdateCode: NULL
PublishUUID: cb327e7c-964a-4e7e-893e-fac43d57a604
TranslationTimestamp: NULL
TranslationStatusCode: NONE
1 row in set (0.01 sec)
[/code]
Thanks
Brendon
Hi Brendon,
I believe this directly ties in with your other issue ;
<a href = "http://www.yellowfinbi.com/YFForum-View-import-failing-on-virtual-table-fields-?thread=128110#p10]View import failing on virtual table fields .
Is this related?
As we already have some of your DB here in the office which could make it easy to test.
Do you have the xml file that we could import? Or does it rely on other tables which we don't have as part of the DB you sent across.
Thanks,
David
I believe this directly ties in with your other issue ;
<a href = "http://www.yellowfinbi.com/YFForum-View-import-failing-on-virtual-table-fields-?thread=128110#p10]View import failing on virtual table fields .
Is this related?
As we already have some of your DB here in the office which could make it easy to test.
Do you have the xml file that we could import? Or does it rely on other tables which we don't have as part of the DB you sent across.
Thanks,
David
Hi Brendon,
at first I thought I couldn't reproduce this issue - importing via the standalone utility was successfully overwriting an existing view of the same name. However, then I changed the view name to "New View" and that did it! it wasn't able to import the view.
I have raised a product defect (task ID 129569) and will bring it up at next week's dev meeting. In meantime, the developers say that it is most probably caused by there being other views of the same name so it's getting mixed up, therefore the obvious workaround would be to use unique view names.
Thanks to your client for that suggestion (i.e. 'New View')
Regards,
Dave
at first I thought I couldn't reproduce this issue - importing via the standalone utility was successfully overwriting an existing view of the same name. However, then I changed the view name to "New View" and that did it! it wasn't able to import the view.
I have raised a product defect (task ID 129569) and will bring it up at next week's dev meeting. In meantime, the developers say that it is most probably caused by there being other views of the same name so it's getting mixed up, therefore the obvious workaround would be to use unique view names.
Thanks to your client for that suggestion (i.e. 'New View')
Regards,
Dave
Hi Dave,
I'm not too sure if I understand 100% here - where can we change the name of the view to remove 'New View'?
When we create a view via the drag and drop process, it always gets given a name and a description, as shown above with the projects screenshot. But, the ViewName field in the ReportView table is always 'New View'.
Is there a way to change this through the drag and drop process that I have missed, or are you suggesting that we should change that via the xml when we do an export?
Thanks
Brendon
I'm not too sure if I understand 100% here - where can we change the name of the view to remove 'New View'?
When we create a view via the drag and drop process, it always gets given a name and a description, as shown above with the projects screenshot. But, the ViewName field in the ReportView table is always 'New View'.
Is there a way to change this through the drag and drop process that I have missed, or are you suggesting that we should change that via the xml when we do an export?
Thanks
Brendon
Hi Brendon,
I think our terms have got mixed up, I was talking about the actual name of the view being New View which was causing my import to fail, but as you know that is stored in the column ViewDescription, so we were in fact talking about different scenarios, and yet I think they are linked because it would be too much of a coincidence otherwise. I am hoping that a developer's investigation next week of the defect will bring something to light as having 'New View' as the ViewDescription was the only way I could replicate an import issue with the standalone utility. Apologies for the confusion.
Regards,
Dave
I think our terms have got mixed up, I was talking about the actual name of the view being New View which was causing my import to fail, but as you know that is stored in the column ViewDescription, so we were in fact talking about different scenarios, and yet I think they are linked because it would be too much of a coincidence otherwise. I am hoping that a developer's investigation next week of the defect will bring something to light as having 'New View' as the ViewDescription was the only way I could replicate an import issue with the standalone utility. Apologies for the confusion.
Regards,
Dave