A new bug fixed: The service_range_serqnr field

Today I have received very good news.
In the next version of Singl.eView CB it will be fixed one of the most awkward bugs of CB application. The bug is related with the field service_range_seqnr in the product_instance_service table. This field takes inconsistent values in some conditions.
As the readers well know, this field gives the number of instances created for the same service_type defined in the same service_item_seqnr row in the product catalogue structure. When you create a new product instance and you add a service, Singl.eView store in the relation table product_instance_service the service item sequence number (the number of the “row” in the product structure definition) created to allocate the new service. If you add more services from the same service_item_seqnr then the field service_range_seqnr raises one unit for each and allows differencing one from another. Then, if you cancel a service, the field service_range_seqnr takes a negative value for this service and renumber the field for the rest of the services with service_range_seqnr greater than the service you are cancelling.
For an active service the field service_range_seqnr it has to be greater than zero. Now, due to the bug an active service can take a value equal to cero or negative. The error appears if you update a service cancelled (that it’s possible from the GUI or for the API). Whenever you update the cancelled version, the renumber process reduces one unit to the rest of the services.

If you want to reproduce the error then you can:

1) Select a product that could have several services with the same service_range_seqnr.

2) Query the database for the product_instance_id
and the service_range_seqnr selected:

Order by

3) Select a service (not the service with the greater service_range_seqnr)
4) Cancel the service
5) Query again
6) update the cancel service as times as you want
7) Query again

What happens if an active service has in the field service_range_seqnr a value equal or lower to zero? That you are going to obtain several errors if you try to cancel this service. You won’t be able to cancel until you correct the value of the field…

That’s all folks ;)



Anonymous Anonymous said...

I need to delete function historical rows.

GUI: Needed to remove all dependencies ie. removing all calls to the desired-to-delete function. Delete both old and current row. Re-create function with saved-off text of current function definition. Too cumbersome.

Archive: Archived out current row. Attempted to purge all records of target function using archive_type = Function, bombed on variable defn dependencies.

I need a clean way to fix in Dev so its promotable on up into production.


Anonymous Anonymous said...

Why aren't you updating your blog anymore? :)


Post a Comment

<< Home