The Forums on slxdeveloper.com are now retired. The forum archive will remain available for the time being. Thank you for your participation on slxdeveloper.com!
|
|
TRIGGERS and STOREDPROCEDURES
Posted: 06 Jun 08 8:58 AM
|
hi,
Can we achieve complex tasks which are not possible in saleslogix AA
using 'TRIGGERS' and 'STOREDPROCEDURES' at the database level.
Ulaga |
|
|
| |
|
Re: TRIGGERS and STOREDPROCEDURES
Posted: 06 Jun 08 10:41 AM
|
| Caveat being there are no remote users, or if there are make sure you use the Saleslogix Provider to make the changes.. |
|
|
|
Re: TRIGGERS and STOREDPROCEDURES
Posted: 06 Jun 08 11:22 AM
|
I must disagree and stress that there are major caveats to using triggers and sprocs. So the comment "no reason not" is incorrect.
SalesLogix security, synchronization, calculated fields, and UTC conversion all are embedded in the SalesLogix OLEDB provider. There are legitimiate and practical reasons for using triggers and sprocs but they are the exception, not the rule. Your best bet is to design your solution without them when possible (which again is the majority of the time). If find you must use them, I highly recommend contracting a business partner that understands the SalesLogix system deeply enough to advise you on your design.
Timmus |
|
|
| |
|
Re: TRIGGERS and STOREDPROCEDURES
Posted: 07 Jun 08 4:11 PM
|
| I feel Nick is right when it comes to developer-added out-of-the-box entities that do not come inbuilt with SalesLogix. How can writing triggers for such entities affect the integrity of SalesLogix/AA? |
|
|
|
Re: TRIGGERS and STOREDPROCEDURES
Posted: 08 Jun 08 9:19 PM
|
If you have remotes, any sprocs or triggers will not have their inserts, updates or deletes sent out to remotes or back to the server unless you somehow run them through the SalesLogix OLEDB provider. All date/time fields in the database (as defined by their definition in SalesLogix, *not* SQL Server) are stored as GMT and the provider does all that translation work for you. If you insert a date in a sproc, you need to make sure you account for that.
Basically, all the reasons Timmus outlined with a little more detail. Trust me - if Timmus & Ryan say it's probably not a good idea, it's probably not.
Jeff
|
|
|
|
Re: TRIGGERS and STOREDPROCEDURES
Posted: 09 Jun 08 2:56 AM
|
All of the points were considerations - NOT reasons not to use them. I already pointed out dont bother using them if you have remotes, but everything else can be worked around...
But to be fair it is much easier to do all of that in your application not in SPs and triggers!! |
|
|
|
Re: TRIGGERS and STOREDPROCEDURES
Posted: 09 Jun 08 9:51 AM
|
Oh, I agree. It can be done. I have a customer with over 50 sprocs in the database. They never had remotes and never will. We made them swear in blood they understood that if they ever wanted them then they would have to start over.
At this point, they're stuck on 5.2 with no reasonable upgrade path - at least without a LOT of work. A technology shift like happened with the provider made upgrading even tougher. The customer could have upgraded to newer versions without remotes - except for the provider. They'd have to modify every sproc to account for GMT as well as the calculated fields. That in and of itself is reason to not upgrade; it'd be too huge of an effort.
But as Timmus said, the caveat is to know SLX deep enough to know what you're about to do. For those of us who have worked with it for a while, it's old news. For someone with limited SLX experience, it could be an accident with big consequences.
Jeff
|
|
|
|
Re: TRIGGERS and STOREDPROCEDURES
Posted: 10 Jun 08 1:59 AM
|
Hi Friends,
Sorry for late reply.since past 2 days i am not feeling well ,i am not able to reply for your comments.
So most person's comment is 'not to use Triggers & SP's ' in database level.
But Jeff is telling that he has customer with over 50 sprocs in database.
Hi jeff,
Can i have the sample of integrating SP's and AA.
Ulaga |
|
|
| |
|
Re: TRIGGERS and STOREDPROCEDURES
Posted: 10 Jun 08 6:21 AM
|
Hi Ulaga,
If you dont know what remote users are then you certainly shouldnt be using SPs or Triggers 
Remote users are Saleslogix users who log into the system using the remote version of the LAN client.
Nick |
|
|
|
Re: TRIGGERS and STOREDPROCEDURES
Posted: 10 Jun 08 6:33 AM
|
Thanks Nick for the answer
When the user raises trigger in the database,what may be the problem in user using the SalesLogix Website?
whether raising trigger in database affects AA.
Ulaga
|
|
|
|
Re: TRIGGERS and STOREDPROCEDURES
Posted: 10 Jun 08 6:50 AM
|
Jeff and Timmus have stated a few of the pitfalls of using them above. I would seriously try getting what you need to work in the client as opposed to using triggers.
There arent really issues that occur in AA using triggers, they affect the client, and data integrity. |
|
|
|
Re: TRIGGERS and STOREDPROCEDURES
Posted: 10 Jun 08 9:46 AM
|
Originally posted by ulaga
Hi jeff,
Can i have the sample of integrating SP's and AA.
|
|
I don't have any examples using SPs with AA - they were all used in 5.2 and web manager. That said, there really is no reason for 99.9% of all implementations to use a sproc in SalesLogix. I hit that .1%, and as I said before, that customer will probably never be able to upgrade - they'd have to start over.
Jeff
|
|
|
|
Re: TRIGGERS and STOREDPROCEDURES
Posted: 10 Jun 08 5:52 PM
|
Please describe the situation you have encountered in SLX where you believe that SPs and triggers are required, over and above what is possible from within SalesLogix using 'standard' means.
The chances are that someone here has the knowledge to solve your problem without compromising your system's upgradeability and capacity to support remotes.
Phil |
|
|
|