I have a existing table Sign-Up which list the users and state an option if they would like to subscribe to the news letter. So in the column (in Table Sign_Up) for newsletter it states "YES" if this has been checked.
I Also have a second table called Subscribers.. suppose i want to add all or specific(column) values of an existing Sign_Up record if the data states Yes they want to subscribe to newsletter.
The purpose of this is to have any records which have said yes to newsletter to update and save to my subscribers table.
Can this be done automatically within phpMyadmin?
Could Triggers help with this?
Related
I want to create a multi-select Contact Lookup.
What i want :
When user clicks on a lookup then he should be able to select multiple contacts from that.
What i have done:
I have created an object and a field inside that object using both
"Lookup" and
"MasterDetail Relationship" and
"Junction Object"
When i try to use this Field for any input text/Field then it always provides an option to select only one value from lookup but i want to have an option to select multiple.
Even in the Junction object i have created 2 master-detail relationships still lookup allows only one value to be selected.Moreover it makes the field mandatory which i don't want.
Links that i followed:
http://success.salesforce.com/questionDetail?qId=a1X30000000Hl5dEAC
https://ap1.salesforce.com/help/doc/user_ed.jsp?loc=help§ion=help&hash=topic-title&target=relationships_manytomany.htm
Can anybody suggest me how to do this.
Its same as we use Email CC/BCC under Send Email option for any Lead.
Even you use a junction object a lookup is just that, it references (looks up to) one other record: when you create a record on the junction object you still have to set each lookup individually and you're still creating only one record.
Master Detail relationships are essentially lookups on steroids, one object becomes the child of the other and will be deleted if the parent object is deleted, they're not going to provide an interface to lookup to many records at once.
If you're not a developer then your best bet is to either just create on junction object record at a time, or look into using dataloader. You could prepare your data in Excel or similar and then upload all the records into Salesforce in one go.
If you are a developer, or have developers at your disposal, then what we've done in the past is create a Visualforce page to do the job. So if, for example, you wanted to link a bunch of contacts up to an Account, we'd have a single account lookup field on the page, then some search fields relating to fields on the contact. Using a SOQL query you can then find all contacts matching the search parameters and display them in a list, where you may want to provide checkboxes to allow the user to select the contacts they want. Then it's just a case of looping through the selected contacts, setting their Account field to be the chosen account.
There are areas in Salesforce (such as the send Email functionality you mentioned) where it's clear to see that bespoke work has been done to fulfil a specific task — another instance of what you want is in the area where you can manage campaign members. This is the model I've copied in the past when implementing a Visualforce page as described.
Good luck!
For adding multiple junction objects at one time, the only solution we have found is a custom Visualforce page, as described by LaceySnr.
For a slightly different problem, where we need to assign many of object B to object A, We have trained our users to do this with a view on object B. We are assigning Billing Accounts (B) to Payment Offices (A). The view on Billing Account has check boxes on the left side. The user checks the Billing Accounts to be assigned, then double-clicks on the Payment Office field on any of the checked rows. A pop-up asks if you want to update only the single row or all checked rows. By selecting 'all checked rows', the update is done to all of them.
The view is created by the user, who enters the selection criteria (name, address, state, etc.). All user-created views are visible only to them.
I want to know how to save edited values in sql server to return to it's value after that.
For example:
I have the user which it's status is working, after an year it's status is "Closed" the status is saved as an id in table user when it is working the id of status is 1 when it is closed i update the id to 2. how can I see that this user from date to date was working and now he is closed.
Thanks for your replies.
You got my question.
But the problem here is that I give here only one example which was user status, but the problem is that I have so many tables which I change they id's. For example I have Id of city, or Id of products etc.
If I save it at the same table of user for example I lost user id because every time I update user it will take a new id, or if I do a user status table I will do 20 or more tables like user status history. Also I want to save the text not only id's. For example the user got e new address I want to say from this date to date he was at previous address and now-days hi live in another place.
Any suggestion please :).
Your question is very unclear, but I think you mean "I have a User table with a Status column, and I need to see a history of status changes because when I change the Status value for a specific user, I lose the previous value".
If that's correct, one simple solution is to add a second table called UserStatus or whatever, and INSERT a new row into it every time the user status changes. You can then easily see the complete history of status changes for each user, and you can also find the current status for any user by querying the 'newest' row for that user.
In principle, the Status column on the User table would be unnecessary if you add the UserStatus table, so you could remove it. If that isn't possible (e.g. you don't control the applications using the table), then you can add a trigger to the User table that populates the UserStatus table automatically when you UPDATE the Status.
My suggestion is to have two columns
One is working/date and closed/date so that you can maintain the history of data.
Say you have a ServiceCall database table that records down all the service calls made to you. Each of this record contains a many to one relationship to Customer record, where it stores which customer made the Service Call.
Ok, suppose the Customer has stop doing business with you and you do not need the Customer's record in your database. No longer need the Customer's name to appear in the dropdown list when you create a new ServiceCall record.
What do you do?
Do you allow the user to delete the Customer's record from the database?
Do you set a special column IsDeleted to true for that Customer's record, then make sure all dropdown list will not load all records that has IsDeleted set to true? Although this keeps the old records from breaking at innerjoins, it also prevents user from adding a new record with the same name as the old Customer, won't it?
Do you disallow deletion at all? Just allow to 'disable' it?
Any other strategies you used? I am guessing everyone have their way, I just need to see your opinions.
Of course the above is quite simplified, usually a ServiceCall record will link to many other entity tables. All of which will face the same problem when they are required to be deleted.
I prefer to set an IsDeleted flag, one of the benefits is you can still report on historical information (all teh data is still there).
As to the issue of not being able to insert another customer with the same name, this isn't a problem if you use an ID column (eg CustomerId) which is generally auto populated.
I agree with #Tetraneutron's answer.
Additionally, you can create a VIEW that lists only the active customers, to make it more convenient to populate drop-down lists and such.
Lets say I have the following 2 tables in a database:
[Movies] (Scheme: Automatic)
----------------------------
MovieID
Name
[Comments] (Scheme: Manual)
----------------------------
CommentID
MovieID
Text
The "Movies" table gets updated by a service every 10 minutes and the "Comments" table gets updated manually by the users of the database.
Normally you'd just create a simple foreign-key relationship between the two tables with cascading updates and deletes but in this case I want to be able to keep the manually entered data even if the movie it refers to gets deleted (the update service isn't that reliable). This should only be a problem in one-to-many releationships from an automatic table to a manual table. How would you separate the manual and the automatically populated parts of the database?
I was planning to add a foreign-key that isn't maintaining referencial integrity and only cascades updates, not deletions. But are there any pitfalls I should be aware of by doing it this way? I mean, except the fact that I might end up with some of the manual data that doesn't actually reference anything.
Edit / Clarification:
Just to clarify. The example tables are totally made up. In reality the DB will contain objects like servers, applications, application notes, versions numbers etc. Server related information will be populated automatically but some application details will be filled in manually. It could be information like special configurations and such. Even if the server record gets deleted the application notes on that server are still valuable and shouldn't be deleted.
I'd suggest you use an import table that gets updated by the service and then populate the movies tables from that. Then you get to keep movies that are deleted in the movies table. Possible tagging them as deleted or obsolete, but you'd still be able to keep them for historical purposes.
I think you should use a soft delete for that scenario. I don't think you want to have comments you don't know which movie they belong to.
Agree; an example route would be to copy the movies table and add a status field which indicates each record's present state (live/checking/deleted). Then the autoimport should go into a temporary table, set the status of all movies to 'checking', then use the temporary table to update the real movies table, setting the movie status to live when it's found in the temporary table. Once complete, set any movie which still has a status of 'checking' to deleted, since they weren't found in the autoimport. At the application end, select any movie which doesn't have status = deleted.
"I was planning to add a foreign-key
that isn't maintaining referencial
integrity and only cascades updates,
not deletions."
Since you appear to be using surrogate keys, updates will not be relevant to foreign elements. Additionally, since you do not care about orphaning data, then why use the referential constraint at all? You use constraints to ensure that something exists, which you do not appear to require in this situation.
Data in one table is referenced by ID to another Table. For example, I have a table of States with ids 1-50. In another table "User" I have a reference to that id ie. state= 4. When I need to update data back to "User", if the state changes, should my code be aware of the numbering of the state data? In other words, if the new state is Alabama id=1, i should enumerate before submitting to database? Or should the DataAccess layer search the datatables for theid for the new state?
The specifics of this depend on what your front end is, but in general you should pass around the id as well as the state name, so when the user selects Alabama, id 1 gets pased back to your DAL so it can set StateID in the user table directly to that with no additional selects.
E.g., if the front end is a web page,
<select>
<option value=1>Alabama</option>
...
</select>
You should never need to perform an additional search check in the db, if your database has a proper foreign key on the user table column that references the states primary key column. Having this will always ensure a legit value is persisted to your user record.