Modify Aspect Object written in VB using Bulk Data Manager
I use "Bulk Data Manager - BDM" to try to update an Aspect's Property (This aspect is an instance of the VB sample "MyData" Aspect System that is available with the Aspect Studio Installation). I found that I cannot save my edited Property to the new value that I entered in the Excel column corrsponds to this Property.
However, When I use a Aspect System written in C++, I succeeded in saving the edited Property. Is this a Bug in the BDM or is there some interface that a VB aspect sysstem must implement?
However, When I use a Aspect System written in C++, I succeeded in saving the edited Property. Is this a Bug in the BDM or is there some interface that a VB aspect sysstem must implement?
Answers
The VB sample "MyData" does probably not support transactions.
a) you can switch off transactions in BDM Options -> Transactions (but this makes bulk operations much slower, e.g. factor 10)
b) or much better, your VB ASO should support transactions (As described in the AEX documentation)
a) you can switch off transactions in BDM Options -> Transactions (but this makes bulk operations much slower, e.g. factor 10)
b) or much better, your VB ASO should support transactions (As described in the AEX documentation)
I have added the code below to "UserControl_WriteProperties" Sub for transaction support :
Dim sys As ABBSystem
Set sys = MyObject.System
Set t = sys.Transaction(False)
MyAspect.EnlistInCurrentTransaction Me
However, when I did switch off transactions in BDM, I still could not save the edited value to the Aspect's Property. When I added this Property from the VB Wizard, VB put a global variable (but private to the class) with the same name as the property. Then when BDM tried to save to the property, it call the "Let Property" Sub and assigned the correct updated value to the variable. But, when the "UserControl_WriteProperties" is invoked, the value of the variable reverts back to the old value, and it is this old value that got saved back to the PropertyBag.
With all these said, I got an impression that there is a need for more than just adding transaction support to be able to save. Can you tell me what else I can try?
---------------
<BLOCKQUOTE><font size="1" face="Verdana, Arial">quote:</font><HR>Originally posted by MartinHollender:
<B>The VB sample "MyData" does probably not support transactions.
a) you can switch off transactions in BDM Options -> Transactions (but this makes bulk operations much slower, e.g. factor 10)
b) or much better, your VB ASO should support transactions (As described in the AEX documentation)</B><HR></BLOCKQUOTE>
Dim sys As ABBSystem
Set sys = MyObject.System
Set t = sys.Transaction(False)
MyAspect.EnlistInCurrentTransaction Me
However, when I did switch off transactions in BDM, I still could not save the edited value to the Aspect's Property. When I added this Property from the VB Wizard, VB put a global variable (but private to the class) with the same name as the property. Then when BDM tried to save to the property, it call the "Let Property" Sub and assigned the correct updated value to the variable. But, when the "UserControl_WriteProperties" is invoked, the value of the variable reverts back to the old value, and it is this old value that got saved back to the PropertyBag.
With all these said, I got an impression that there is a need for more than just adding transaction support to be able to save. Can you tell me what else I can try?
---------------
<BLOCKQUOTE><font size="1" face="Verdana, Arial">quote:</font><HR>Originally posted by MartinHollender:
<B>The VB sample "MyData" does probably not support transactions.
a) you can switch off transactions in BDM Options -> Transactions (but this makes bulk operations much slower, e.g. factor 10)
b) or much better, your VB ASO should support transactions (As described in the AEX documentation)</B><HR></BLOCKQUOTE>
in Aspect Express Builder you need to switch on "Implements transactions" (available in the wizard when you add a component)
I did switch on "Implements transactions" option within the Aspect express builder. It still did not have the desired result. The other side effect of turning on this option is that the property page for updating the Aspect's property no longer works.
---------
<BLOCKQUOTE><font size="1" face="Verdana, Arial">quote:</font><HR>Originally posted by MartinHollender:
in Aspect Express Builder you need to switch on "Implements transactions" (available in the wizard when you add a component)<HR></BLOCKQUOTE>
---------
<BLOCKQUOTE><font size="1" face="Verdana, Arial">quote:</font><HR>Originally posted by MartinHollender:
in Aspect Express Builder you need to switch on "Implements transactions" (available in the wizard when you add a component)<HR></BLOCKQUOTE>
In the User’s Guide page 61 and 63, describing “Multiple ASO solutions” there is an error in the parameter supplied with the “EnlistInCurrentTransaction”. The argument “Me” shall not be used as it can’t be assured that the ASO is available as long as the reference exists.
Please use the following to circumvent the problem:
Ambient.aspect.EnlistInCurrentTransaction Ambient.aspect.Aso("MyAsoName")
Where “MyAsoName” is the name of the control.
The problem is also present in the source code of the examples “MyVbDataLayers”, “MyVbDatas”, and “MyVbDataSplit”.
The problem will be fixed in the next version of AEX, and the need for a call to EnlistInTransaction will then be removed.
Please use the following to circumvent the problem:
Ambient.aspect.EnlistInCurrentTransaction Ambient.aspect.Aso("MyAsoName")
Where “MyAsoName” is the name of the control.
The problem is also present in the source code of the examples “MyVbDataLayers”, “MyVbDatas”, and “MyVbDataSplit”.
The problem will be fixed in the next version of AEX, and the need for a call to EnlistInTransaction will then be removed.
Your latest suggestion now enables saving the edited property. However, It did not solve the side effect that prevented the property page from working. I modify the existing "MyDataSplit" VB project slightly so that one of its Property (MydataName) now, in theory, could be configured with a Property Page. However, Aspect Express only allow a single "default" view, which is the View ASO itself, and a Data ASO. The problem seems to be that that you cannot the attached the Property Page as a second "view" to the "default" view.
--------
<BLOCKQUOTE><font size="1" face="Verdana, Arial">quote:</font><HR>Originally posted by LeifSjostrom:
<B>In the User’s Guide page 61 and 63, describing “Multiple ASO solutions” there is an error in the parameter supplied with the “EnlistInCurrentTransaction”. The argument “Me” shall not be used as it can’t be assured that the ASO is available as long as the reference exists.
Please use the following to circumvent the problem:
Ambient.aspect.EnlistInCurrentTransaction Ambient.aspect.Aso("MyAsoName")
Where “MyAsoName” is the name of the control.
The problem is also present in the source code of the examples “MyVbDataLayers”, “MyVbDatas”, and “MyVbDataSplit”.
The problem will be fixed in the next version of AEX, and the need for a call to EnlistInTransaction will then be removed.</B><HR></BLOCKQUOTE>
--------
<BLOCKQUOTE><font size="1" face="Verdana, Arial">quote:</font><HR>Originally posted by LeifSjostrom:
<B>In the User’s Guide page 61 and 63, describing “Multiple ASO solutions” there is an error in the parameter supplied with the “EnlistInCurrentTransaction”. The argument “Me” shall not be used as it can’t be assured that the ASO is available as long as the reference exists.
Please use the following to circumvent the problem:
Ambient.aspect.EnlistInCurrentTransaction Ambient.aspect.Aso("MyAsoName")
Where “MyAsoName” is the name of the control.
The problem is also present in the source code of the examples “MyVbDataLayers”, “MyVbDatas”, and “MyVbDataSplit”.
The problem will be fixed in the next version of AEX, and the need for a call to EnlistInTransaction will then be removed.</B><HR></BLOCKQUOTE>
In the users guide of the next release, we will strongly discourage implementation of view and data/business logic in the same component. Instead a layered solution should be used. That is, one component with logic and persistency, and one or more view components. Do not use property pages, instead use a user control for each aspect view.
The problem with view/persistency in the same component is that, when the component has an aspect view, then the object manager needs to create a new COM object each time a interface on the component is asked for. This means that multiple instaces will be present during the transaction, and an arbitrary one will win the persistency race.
Wrapping a third party component can be safe as long as it is used with the potential problem kept in mind.
[This message has been edited by Lennart Myrehed (edited 15-01-2002).]
[This message has been edited by Lennart Myrehed (edited 16-01-2002).]
The problem with view/persistency in the same component is that, when the component has an aspect view, then the object manager needs to create a new COM object each time a interface on the component is asked for. This means that multiple instaces will be present during the transaction, and an arbitrary one will win the persistency race.
Wrapping a third party component can be safe as long as it is used with the potential problem kept in mind.
[This message has been edited by Lennart Myrehed (edited 15-01-2002).]
[This message has been edited by Lennart Myrehed (edited 16-01-2002).]
Add new comment