how to delete a particular product from m_product table in openbravo , Because it has triggers and are interlinked with other tables
I don't think doing a SQL delete is a good choice, since there are some tables related with a particular product (like accounting information).
At application level, if the product is already referenced from another table (like an Order), you wont be able to delete it. However, you can always de-activate the record, achieving a logic deletion of the product.
When you delete using database queries, it will automatically prompt you the linked items where it is being used with the table names. You can remove the dependencies there. If you want to automate it, refer the linked items implementation in openbravo and use that as a base to find out where it is linked and remove them.
Thanks,
Shankar
You may use following options
1) Instead of deleting entry you may consider marking product as inactive or discontinued, so that product will not be available/visible on other windows and reports
2) Delete all linked items first, then delete product entry from UI
3) If you are deleting, using SQL statements - first delete all references(linked tables data) or temporarily turn off triggers and delete
Related
I am trying to create a categorized view of all Notes documents that have a field with exact same value, i.e. there is a field for Contractor Name and I want to create a view that lists each Contractor and the documents that relevant to each. How do I do this? I have tried view formulas like the following but no success as yet
SELECT #IsAvailable(Contractorid) & #Count(Contractorid) > 1
SELECT #Count(#IsAvailable(Contractorid)) >1
Nsf databases are no relational databases. The count of different documents with a unique value in a specific field cannot be used to build a view selection formula.
You could write an agent, that runs through all documents and counts them and puts all with count > 1 in a folder, but this is quite a lot of LotusScript code and needs some advanced knowledge.
The other possibilit would be to categorize the view by ContractorId and add one column before that categorized column: simply use 1 as column formula and select "display totals" in the column properties as well as "hide details".
Then at least you have the information, how much documents are in each category, but unfortunately you cannot filter by it and you cannot sort by this column.
A third possibility would be to use an xpage interface, but that is even more work to do and a completely different story developmentwise.
This is similar to view to identify duplicates. My approach is to use folder.
Make a new folder with design of your view. Instead of (not working) selection formula use short LS code as an action, or QueryOpen event (make sure only one user runs the script).
The code should cooperate with another (hidden) view sorted by Contractorid. Make a ViewNavigator for that view and traverse through it with simple logic - if previous entry has the same Contractorid as the current one, put both documents into folder**. That way you will get list of all documents with duplicate Contractorid. Make sure to wipe all the current content from the folder at the start.
** This can be optimized further by slightly more complicated algorithm to handle first duplicate diferently - for more than two duplicates this algorithm makes extra calls of PutInFolder method.
I'm looking to get some guidance with Sharepoint 2010. I am working on a project which requires a system that would inform concerned users of an outages with their applciation and provide regular updates via email (worflow).
I can accomplish most of the tasks with a simple custom list and workflow. Users would be able to input their start/end time of the outage, description and their update. With a workflow an email would be sent to the concerned users with all the details.
Where the problem starts is that, we have to provide hourly updates on an outage. So I would need to be able to add new update fields dynamically for every new updates and then be able to send all the updates via an email workflow.
At the moment I am just trying to figure out the best way to go about this. I tought that a simple custom list would be sufficient but looks like ill need to create a more complex system. Perhaps ill need to create 3 custom lists, 1 master list that would gather the details from list 1 (cotnains the description, start/end time) and the list 2 (contains updates) and some how link the together.
Would anyone have any advice about this?
I would create 2 lists: 1 main with all details and another one with updates and added multi lookup field to the first list.
OR even better -
added lookup field to the second list and when item is created - set lookup to the item in the list 1. Then you would be able to get all items from the list 2 (updates) by the item in the list 1.
Hope it makes sense.
Regards,
Andrey.
I would consider having following 4 fields apart from whatever you need right now.
1. Update
2. Outage (choice yes/no)
3. Previous updates (hide it on Edit form)
4. latest update hidden (hide this on edit form)
I would use one list. Let the workflow run whenever a new item is created or an existing item is updated.
For new Outage items send the outage email.
For updates:
Every hour check for update on the item
If there is any update then copy the value to latest update and previous updates. Clear the value of update column.
Send email with latest update value.
Once outage is over user updates the update field and makes outage over to yes.
At this point of time the workflow is complete.
In my database I have a table called Price.
I want to hide this table. Is this possible ?
If the user does not have SELECT permissions on the table then they will not be able view the table in Object Explorer.
i.e.
deny select on TableToHide to UserThatShouldntSeeTable
go
Depending on your particular circumstances, you may be able to use the Tables "filter" functionality. You can filter your list of tables in the Obj Explorer to view only those tables that satisfy certain criteria. (Unfortunately, you cannot HIDE certain tables, you can only SHOW certain tables, while hiding all others.)
To do this, simply r-click on the "Tables" node, and select Filter -> Filter Settings. This opens a dialog which allows you to specify the criteria (name, owner, date of creation, etc) by which you want to specify which tables should be visible. More details can be found in this post.
It's too bad you can't save filters (based on schemas, for example), but at least it's a start.
[Now if only we could do the same thing with the list of Databases on shared servers...!]
I got a question about the behavior of lookup fields when importing data. I wonder how the lookup fields behave when the list they point to is being replaced/imported. To explain the issue, I will provide a quick example below:
As example, assume we have these two sharepoint lists:
Product Types
-------------
+ Type Name
+ Code Nr
+ etc
Products
--------
+ Product Name
+ Product Type (Lookup field to list "Product Types")
+ etc
In my scenario, the Products List contains production data on the production Sharepoint platform. It is filled with data by the business users.
However the Product Types list contains rather static data and is maintained by the developer.
Now after a development cycle, the developer wants to deploy his new webparts and his new data (product types list). The developer performs the following procedure:
On the dev machine: Export "product type" list using stsadm
On the production machine: Delete all items in the "product type" list
On the production machine: Import the "product type" list using stsadm
This means we basically replace the "product type" list on the production server while keeping the "product" list as it is.
Now the question:
Is this safe? Will the lookup references break under certain circumstances?
Any downside of this import/export procedure?
What happens if someone accesses a "product" during the import? Will the (now invalid) reference clear its own content (become a null value).
What happens if the schema of the "product type" list changes (new column)? Will this cause any troubles?
Thanks for all feedback and suggestions!
Update 1
The imported "product type" items have the same IDs as previously deleted ones.
Update 2
Started a bounty to get some more feedback/opinions.
We have had this exact same scenario before. This is a little tricky, depending upon how you will approach it.
1) Delete and Recreate Product Type list through UI
If you delete and recreate the lookup List(Product Type in your case) through UI, then you will lose the connections because the List's id GUID will change upon recreation. So do not go that route.
2) Delete and Recreate Product Type through a Feature
If you had created the Product Type list through a feature.xml file using the <ListInstance> element, then if you delete that list and then recreate it using the same feature (basically Id attribute of ListInstance remains the same, number of list items, i.e. the number of <Row> elements, may change), the association would be maintained. So if you were adding 5 more product types, then if you had created the list using a feature, you could just delete the list and provision the new one using the same feature with extra info for new items and everything would just work!
As a side note, this is the better approach because if you have to do the upgrade on a lot of servers, then rather than doing list export import via stsadm, feature deactivation and activation is a much more recommended solution. This is how we did it.
3)Deleting all list items from Product Type and adding new ones (list is never deleted)
If you are linking the lookup field (in Product List) to the ID field of the lookup list(Product Type), you have to remember that ID is auto-incrementing, so if you delete all items and then add new ones, then their ID's would be different. Say you had 5 items with ID's (ID field is not shown in UI while editing in Datasheet view) 1-5 in the list. If you delete them and add new items, their ID's would start from 6 and not 1 again. So if your lookup field had link to the item with ID 1 in it, then this method is not going to work because there is no item with ID 1 in the Product Type list anymore. So you might want to really try this out before going to production with this method.
4) Editing the list in place
If the list is not extraordinarily huge, and you only have to make this change to one or two instances, could you not just edit the list directly in the datasheet view on the prod server? When editing in datasheet view, do not delete the item, but just overwrite the values of its columns. And you can add more items if you want. This will make sure your ID's are valid.
I have mostly talked about adding new items to the list. Now if you were deleting existing items, then your lookup fields will be affected because assuming you linked the field by ID, the ID is not present anymore since the item has been deleted. Basically, any method you use, maintaining your ID's is critical.
Now regarding your doubts/questions:
I am not too sure about stsadm export import for a list (never done it myself), but stsadm can be tricky as some operations will work on certain scopes only. So you better try out your exact scenario on a dev env.
What happens during an import is tricky again depending on the exact timing. I am sure SP has its own concurrency mechanisms, but you cannot have a definitive answer as it might probably be different based on the stage of the import. If possible, recommended approach is to do the import during a planned downtime.
Regarding changing schema of the list, a change in the schema of a list will not affect the existing list instances (for the most part). If you do this through UI, I believe SP makes changes to the content DB directly. I am not certain how you intend to do this, but if you were to add a column to an existing list using a feature, the way to do this is during feature activation by adding a new content type to the list and adding your new column to this content type. This way you add the column but do not affect the existing list items.
Good luck...
There are two components to a particular lookup: the field, and the field value. The field value only contains the ID of the item(s) it refers to, and the display field. This information is meaningless without the field, which specifies what list to look at and what field to use as the display field.
The primary reason that a Lookup will break occurs on the field scope: either the list it referred to no longer exists, or the list does not contain the required field. These would generally happen if you deleted and recreated the list, but you aren't doing that. If you do break a lookup's list reference, then the only thing you can do is re-create the lookup, because you cannot configure the list reference for a lookup field once it is created.
The downside of your import/export procedure is that you lose the validity of all currently existing lookup values. A lookup maintains its integrity based on the ID of the item it references. So when the display field changes, it still refers to the same item. If you delete the item, then the lookup no longer references it, even if you create a new item that has the same value for the display field. So you would have to reassign all of the products to the new product types.
It should be noted that if you were to revert the deletion of that item, it would return to being on the lookup! The reference to that ID is kept until the actual lookup value is updated (such as by editing the Product).
All of your now invalid references will be null for purposes of interaction. You won't see anything on display forms, and you won't have the options when you try to update the product. When you do update the product, you update it to what you just set it to, which since you can't set the non-existent IDs, means that there are no more references to those IDs.
Any changes to the Product Type list's schema that do not affect the display field specified for the lookup will not have any effect on the lookup integrity. If you do change the display field in any fashion, and of course if you delete it, then it will break in the same fashion as with the list reference. However, you can set the display field, both in the UI and in the object model, so it is easy to fix this.
I have a WSS 3.0 site that I use for change management. There are three primary lists on it -- a bug list, an enhancement list, and a release list. The release list has two lookup columns that provide a list of bugs and enhancements that are included in that particular release.
I am trying to figure out how to filter the bug and enhancement list to include only items that have not already been included in another release. All the docs and examples I have seen regarding filtered lookups deal with a query on the list itself. For my situation, and if this was a SQL query, I would need to use a LEFT JOIN to generate the list.
To use SharePoint lists something like relational tables, you should try out SLAM (SharePoint list association manager), that is just what you need for this situation.
After you've set up your relations, you will then have a database you can use to query and determine if value has been used or not within your custom filtered lookup field.