Ranger Hit with bow (Ranged hit) =
([Ranged Attack DPS] + ([Ranged Weapon DPS]) * Talent * Buff) / (Ranged Hit Chance %)


So essentially your attacks are based on:

Ranged Attack DPS = 2*(Ranged attack power) + (Attack power)


Critical hit = 200% damage

So if you have 50% crit chance, that only increases your dps by 50%


So.....

DPS = ((((2*Ranged Attack Power) + (Attack Power)) + (Ranged Weapon DPS) * Talents * Buff) * (1+ .01*Crit chance)) / (.01* hit chance %)) / (Weapon Attack Speed ^1)


So if you're a Archer you will want ranged attack power because you're ranged attack power is counted double. Crit will double this again making it count 4 times.

If you're a assassin you will want critical chance because you're attack power is only counted once, rather than crit that counts it twice.

Assassin build with hints of archery

In a ranger you need agility and crit chance mainly, ranged attack power is good too.

In dungeons just sit back and provide dps. Watch out for bosses area attacks and make sure to not take aggro from the tanks when casting snipe. If there are many mobs then use attacks like split shot and explosion shot.

At level 60 you will want to have rune gear to get into dungeons. You will also need bloodmoon as a necklace and a good bow to start out with (such as lightning bow, or wind cutter). Complete dungeons in this order: Relic's key > Knahswas Prison > Eristars Temple. Get all the gear from the dungeon before moving onto the next one. Be warned though, getting teams as a ranger is tough due to the high competition.

As you run (Legendary) dungeons your exhaust starts to fill up. The more time you spend inside the dungeon the more exhaust you will use up. Once your exhaust is at 100% you will not be able to enter any of the three dungeons on legendary mode. Depending on the dungeon and team skill you may be able to complete anywhere from 3-7 times. Exhaust resets every 24 hours.

As a ranger you will need to know how to pull bosses. To pull a boss remain in sneak and walk to a bosses location. Between sneaks you will have a 1s cooldown on sneak. You need to stop in a spot momentarily to resneak and continue. Once you get to the boss make sure you are only within range of the boss and no other enemies. You can then attack the boss. After you attack him quickly quit the team by going to the team menu then clicking quit. Wait for an invite and proceed back inside to help kill the boss.

Appstore security: 5 lines of defence against malware

The booming smartphone industry has a special way of delivering software to end-users: appstores. Popular appstores have hundreds of thousands of apps for anything from online banking to mosquito repellent, and the most popular stores (Apple Appstore, Google Android market) claim billions of app downloads. But appstores have not escaped the attention of cyber attackers. Over the course of 2011 numerous malicious apps were found, across a variety of smartphone models. Using malicious apps, attackers can easily tap into the vast amount of private data processed on smartphones such as confidential business emails, location data, phone calls, SMS messages and so on. Starting from a threat model for appstores, this paper identifies five lines of defence that must be in place to address malware in appstores: app review, reputation, kill-switches, device security and jails.

Relic island glitch

Ok here's what you do. Walk back to the island with the purple fog. The arrow does not point to the correct location. Stand on the island in front of the pillar facing the ocean, now walk toward the ocean (almost to the edge) and use the item in your bag, not the detector but the other one that looks like a plant, it's description says something like "purifies the air".

Hope this helps

I find myself often searching for services, especially when I'm in a new area. Hopefully this will be useful to some. Tanned Land is not filled because I do not have an Orc or Undead character. If you see any mistakes, please let me know an I'll correct them as soon as I can.

Realm Liking

Mage hybrid build for O&C that has some decent tips

Mage build for O&C that's best for solo players

Those who have had a phone lost or stolen are familiar with the horrors that follow: the thief (or the person he sold your phone to) starts to send texts as you to your family and friends, leaving you scrambling to de-activate the device as soon as possible. For modern iPhone owners, though, such a phenomenon should be in the distant past thanks to the advent of remote wipe capabilities, right?

Perhaps not. Some unlucky iPhone owners are beginning to discover that, despite their best efforts to remove all information from their stolen phones, thieves and unsuspecting buyers are still able to send and receive iMessages as the original owner—even after the device is registered under a new account. Almost nothing seems to work—remote wiping, changing Apple ID passwords, or even moving the old phone number to a new phone—and users are becoming more than frustrated that thieves are so easily able to pose as them.



What's happening

Our attention was drawn to this story by Ars reader David Hovis, whose house was recently burglarized and his wife's iPhone 4S was stolen. According to Hovis, his wife deactivated her iPhone with her carrier, remote wiped it, and immediately changed her Apple ID password—"we picked up a new iPhone the next day, figuring that our insurance would end up paying for it," Hovis told Ars.

For most users, this would be the end of the story. The phone number had been transferred to a new device and the old one had been deactivated; what more is there to say? A lot, apparently, and in the form of iMessages. The thief who stole Mrs. Hovis' iPhone had sold the device to an unsuspecting buyer elsewhere in the state, and the buyer had begun sending and receiving iMessages from the phone as Mrs. Hovis—even though the stolen phone had apparently now been activated under a new number.

Hovis iMessaged back and forth with the new owner—his iMessages, incidentally, going to both his wife's new phone and the old phone at the same time—but the new owner came off as confused and uncooperative, and the whole situation seemed to be at a dead end. That's when Hovis began searching online, discovering that such a thing has happened to other iPhone users as well.

In a MacRumors forum thread from late October/early November, multiple users tell very similar stories about stolen iPhones and misdirected iMessages. The original poster of the thread remote wiped, changed his Apple ID e-mail and password, suspended his service through Verizon, and iMessages sent to him still went through to the stolen phone. Another user named PDiggles said his stolen iPhone was being used by someone going by "BigDaddy," but when PDiggles' friend tried to iMessage PDiggles, BigDaddy had replied back saying the friend had the wrong number (indicating that the phone had indeed been activated under a new number).

A separate thread posted on the Apple Support boards discusses the same issue. A user named mindy1285 says her stolen iPhone 3GS is still receiving iMessages sent to her phone number, even though she already has a new phone activated on that number. Further down in the thread, she points out that the person who now has her stolen 3GS isn't receiving regular phone calls or even normal SMSs sent to her number—only iMessages sent from other iPhone users appear to be making their way through to the stolen phone.

Why is it happening?

We reached out to Apple to ask why this seems to be happening and how it can be prevented, but the company has not responded to our request for comment. So we turned to iOS security expert Jonathan Zdziarski for his opinion on how a stolen (or even just an old, retired) device could be holding onto an iMessage identifier.

"I can only speculate, but I can see this being plausible," Zdziarski told Ars. "iMessage registers with the subscriber's phone number from the SIM, so let's say you restore the phone, it will still read the phone number from the SIM. I suppose if you change the SIM out after the phone has been configured, the old number might be cached somewhere either on the phone or on Apple's servers with the UDID of the phone."

In other words, iMessage may be pulling the old phone number from a cache somewhere and continuing to use it on the device if the SIM was removed after it was configured as a new phone. We were unable to test this theory (and keep in mind that it's just a theory), but it certainly sounds like one of the more logical explanations for this phenomenon.

But my iPhone is still stolen. Now what?

This could be the first major kink in Apple's iMessage setup since the service was rolled out as part of iOS 5 in October. Otherwise, iMessage works well as a seamless replacement for SMS between those using iOS devices, and users generally seem quite happy with the service. So what are you to do if your iPhone is lost, stolen, or just resold and you don't want your iMessages going through to the new owner?

The original poster from the MacRumors forum thread, andrewhdn, eventually said he was able to resolve the issue by registering his new iPhone under a brand new Apple ID and canceling his old Apple ID completely. (This shouldn't have worked, according to what AppleCare and iTunes representatives told him originally, but he claims his iMessages "work fine now.") There's one major downside to this option, however: ditching an Apple ID completely means that you no longer have access to your past music and TV purchases through iTunes—apparently "not a big deal" for andrewhdn, but we can see this being a sticking point for those who buy lots of media.

Have any other Ars readers run into this problem? If so, what were your solutions (if any) to making sure your iMessages weren't going to the wrong place? We'll continue to press Apple on this issue to see if we can get further clarification, but in the meantime, make sure to keep an extra close eye on your iPhones so they stay out of the wrong hands.
Update: Twitter user Kim Hunter told me that he spoke with "Apple [security]," who told him it's not a security problem and to turn iMessage off on the offending device. When I pointed out that you can't turn iMessage off on a device that has been stolen because it's not in your hands anymore, he agreed: "exactly, i found the issue when i put my sim in a friends phone to activate it. then they were able to send/view/obseve all my mess."



Read the comments on this post

He’s not a big fan of Apple, apparently.

From iOS and Android to BlackBerry and Windows Phone, the app store model has become the main way mobile device users find, download, and update their software. And with employees increasingly begging for access to corporate resources from smartphones and tablets, IT departments are starting to wonder whether they should jump into the app store business themselves.

"The public app store is kind of the wild, wild West," Forrester analyst Jeffrey Hammond tells Ars. Private app stores, hosted for the employees of a single business, are receiving “a lot of interest from the clients I talk to. Folks realize that self-provisioning is the long-term trend."


Private app stores are both a concession to the consumerization of IT, giving employees what they need in handsets they like, and a technology that can help IT administrators take control over how employee-owned devices are used for work. Corporate app stores are in their nascent stages today, but some big companies (notably IBM) have already built mobile stores for their own employees. Other vendors want to make private app stores accessible to businesses that don't have the staff and resources to build their own.

"One thing we don't see a lot today that will be commonplace within the next three years is just about every company [with at least 100 employees] will have their own corporate app store," predicts Dan Croft, CEO of Mission Critical Wireless, which helps businesses manage mobile deployments. Croft likens the emergence of private app stores today to intranets in the 1990s.

Private app stores won't address all the security and management concerns caused by the consumerization of IT. Nor will they, by themselves, unlock the full potential of employee-owned devices to improve productivity. But they could become an important tool for businesses that have enough employees and use cases to make the app store model a justifiable expense.

Meet the new app store, same as the old app store

Private app stores look and function much as you might expect. End users see an app store, separate from those run by smartphone backers like Apple or Google or Microsoft, from which they can download applications that their employers have developed or purchased. On the back end, IT administrators manage which employees get access to particular apps, ensure that updates are pushed out in a timely fashion, take advantage of built-in analytics tools, and even remotely delete apps from user devices when necessary.

Granting employee-owned smartphones more access to company data does carry some risk. Although a business controls what it puts in its own app store, employees can still visit malware-infected websites or download malicious applications from the regular app stores, which has particularly been a problem with the Android Market. Expanding access to corporate resources from phones and tablets also increases the chance of an employee leaking confidential data, intentionally or otherwise. Businesses will naturally want to impose restrictions, but employees may bristle if these are too onerous. To take just a single example, the question of whether it is legal (and appropriate) for businesses to remotely wipe employee phones remains unsettled.

Private app store vendor Partnerpedia's storefront for iPhone

But there is hope. New technologies can isolate the corporate and personal components of a smartphone. BlackBerry's Balance technology lets IT shops keep a user's personal information isolated from business information with separate partitions for each, for instance. Similarly, VMware has developed a hypervisor for Android phones that creates a virtual machine in which corporate data and applications are stored separately from a user's personal data and applications. If businesses get the security model right, employee-owned mobile devices can move from being treated as a threat to being treated as a valuable resource.

Big Blue shows the way

IBM is a great example. The 400,000-employee company built its own app store called WhirlWind. It was initially just for BlackBerry phones but is now being rolled out to iOS and Android devices in pilot trials. So far, 35,000 IBMers use WhirlWind, the vast majority of them from BlackBerrys. IBM started developing the concept late in 2009 and the app store, a Java-based application running on IBM's WebSphere application server and DB2 database software, was in production by late 2010. While users on different mobile platforms see their own IBM app store, with some apps being available on only one platform, the IT folks on the back end can manage them all from a single console. And each app undergoes a code review before distribution.

IBM's WhirlWind storefront on an iPad

The store connects users both to IBM-specific Web applications and to native apps that can be downloaded onto a user's device, some of which were developed by IBM itself and others by vendors who contract with IBM. Widely used programs available through WhirlWind include "Blue Pages"—a Web-based app that works a bit like a private version of Facebook—and a version of the Sametime IM app customized for IBM employees and available as a download.

In the future, the WhirlWind app store will provide more tools for performing common business tasks, like managing travel and submitting expense reports, says Bill Bodin, IBM's CTO for mobility. The store isn't just for phones, either. IBM has rolled out WhirlWind to the iPad and plans to produce a version optimized for Android tablets, too.

Naturally, the highly technical workforce at IBM has contributed numerous applications to WhirlWind.

"It's really been a great melting pot for internal applications," Bodin says. "We have dozens of applications that have been submitted by developers and our brands [vendors] alike. It's not just a grass-roots effort anymore."

IBM has moved slowly from the locked-down BlackBerry environment to one that welcomes iOS and Android. Bodin says IBM worries especially about devices being jailbroken or compromised.

"You run the risk of having a rogue application on there that accesses private data and reports and broadcasts information as it sees fit," he says. IBM is using VPNs, password requirements, and endpoint management tools for its own workforce, and is launching a hosted service for IBM customers that ensures personal devices comply with corporate security policies.

IBM WhirlWind on a BlackBerry


Can private and public app stores live together?

IBM has not gone the route of preventing employees from downloading programs from public app stores. But Dan Croft of Mission Critical Wireless says it's possible some businesses will try to prohibit downloads from non-corporate stores. Employees won't want to give up control over their own tools, so virtualized phones may offer an appropriate compromise.

"The business side of my virtualized device may only be able to get to apps in the corporate app store. The personal side may be wide open," Croft says. "We're going to see this mixed-up, jumbled-up world."

While IBM hasn't made its private app store technology available outside of IBM, several factors are making it possible for businesses to build their own. On the iOS side, two Apple programs play a key role: the App Store Volume Purchasing program, which lets businesses buy apps in bulk for distribution to employees, and the iOS Developer Enterprise Program, which gives developers the tools to build and distribute in-house apps to the iPhone and iPad. The distribution model for Android is more wide open, so hosting individual app stores is simpler.

For end users, custom app stores can be significantly easier to use than the previous "solutions" they replace. Cimarron Buser, vice president of marketing for app store vendor Apperian, says businesses that build their own apps for the iPhone often end up with a disjointed installation process involving e-mailing files to people and syncing devices with iTunes. "One becomes tired of that pretty quickly, because it's extremely difficult to maintain, people don't follow directions, and it's not very scalable," he says.

Talecris Biotherapeutics learned this the hard way a couple of years ago when an internal iPhone app went out on CD to 60 salespeople as part of a trial. "They were asked to follow a 15-step process that included loading the CD on their laptops, downloading the app to iTunes, and syncing with their iPhones," according to a CIO.com article. The deployment success rate? A mere 50 percent. The company ended up turning to Apperian, becoming a beta customer before the vendor's app store platform was generally available.

Controlling enterprise software on employee devices

Using these custom app platforms, IT administrators can distribute applications over the air and enforce polices. They can restrict employees from downloading certain applications based upon job role, and they can disable applications if employees fail to install updates. Keeping applications up to date is often important in regulated industries, Buser notes.

Some Apperian customers are using the company's platform for just a couple of apps, while others have over 100. The platform works with iOS and Android, but Buser says most of the custom development of business apps he's seen so far is on iOS. "It's taken longer for Google to become adopted in the enterprise," he says. "There are security concerns around the devices."

Apperian is considering expanding to Windows Phone and BlackBerry, but "part of the challenge is if we did that today I'm not sure we'd have a single customer building in-house apps for those platforms," he says.

Android tablet with a fictional customer's Apperian app store.

For users, the Apperian app store on the iPhone, iPad, and Android devices provides a familiar experience with application categories, a section for updates, and screenshots and videos re[…]

Love mobile culture LOLs & FAILs? Head over to FAIL Blog’s newest site, AutocoWrecks!

Even if you use your Apple iPhone strictly for play, it pays to ensure that you're checking your e-mail, surfing the Web via Wi-Fi and accessing various content and services in the safest possible ways. You can follow these six tips in a matter of minutes, and potentially save yourself weeks of damage control.

RT @sambowne: ty @alexlevinson 3 Major Issues with the Latest iPhone Tracking “Discovery” << &

The rising tide of mobile computing, driven by the introduction of consumer devices such as the iPhone and iPad, is crashing against the shores of many an IT shop. Most IT organizations have lived on a diet of corporate policy restrictions and liberal use of the word “No!”, unfortunately their time has come. IT can [...]

Even though the iPad is barely birthed, there is already a push to provide payment applications for the device. It's time to pull the emergency brake on this trend. Are these applications PA-DSS certified? Do they have swipe devices with crypto hardware built-in? Has the Pin Entry Device been rigorously tested and meet all the PIN Transaction Security Guidelines? There are so many things consumers should know about the security of these new methods of payments *before* they allow their credit card to be captured by an iPad or iPhone. Is the card's Personal Account Number (PAN) encrypted at the moment it is swiped by the device? Does the device establish an encrypted tunnel to transport the transaction to the payment gateway? Doe the iPad store the PAN? Is that storage encrypted or unencrypted? Does the processor support a tokenization scheme to keep the iPad out of PCI scope? Is the payment app the only thing running on the iPad?
read more

The Internet was buzzing a few weeks ago with Charlie Miller’s iPhone SMS exploit. Reading the vague details available in different news stories it reminded me of some work I had done many months ago that involved a USRP, OpenBTS, and several different phones. The results were pretty spectacular for the same reason Wifi fuzzing found tons of problems: when a developer assumes that there is strict control over both ends of a transaction they don’t do as much error checking as they should. After all, since it's only your code (or other code from friendly people) sending data, then the code receiving data doesn't have to check input.LORCON helped disprove that idea with Wifi. The USRP+OpenBTS combo is doing the same for GSM based handsets.The crinkly bits is that to find bugs with OpenBTS, you have to trick a cellphone into connecting your hostile base-station rather than a commercial cellphone tower. This is why I found Charlie Miller's and Collin Mulliner's research interesting: they claim they discovered a way to inject SMS locally for testing that wouldn’t be seen by your provider, making fuzz testing easier. I have seen local SMS injection exploits before but never for the iPhone, so I thought i’d spend a day poking around and see what I could come up with. The rest of the blog post is an accounting of how I spent the time searching for this vuln, how I duplicated a vuln that fits their description, and what to do next.The first thing I needed was an iPhone. I have one I use everyday, but I'm afraid of bricking it. Instead I dug up an old first-gen iPhone. I assumed that executing the fuzzing code mentioned in the abstract would require jailbreaking the phone since it seems impossible to accomplish that task within the iPhone SDK. I was delightfully surprised to find that using redsn0w made jailbreaking the 3.0 firmware a snap. I installed some basic apps I thought I would need, including the iPhone toolchain (you can compile code directly on the iPhone), ruby, OpenSSH, and the mobile terminal. After looking through the Cydia repository I saw there were some apps that allowed for the sending and receiving of SMS messages. These seemed to be a great place to start. The first example I found is called "aSMS", which has a Google Code project: http://code.google.com/p/iphone-sms/The aSMS app is a bit odd, the front-end is in the browser, and the backend is a built-in webserver on the iPhone. I spent a few minutes going through the source and found it used what appears to be a baseband debug trick to send messages. The word "baseband" is one way of referring to the separate CPU and operating-system that runs the cellular radio. "Baseband hacking" is were do things like unlocking a mobile phone so it can run on any carrier, and enable features a carrier doesn't want you to use (like tethering or MMS). More specifically the trick uses the device /dev/tty.debug. Googling for "tty.debug" and iPhone led me to another Google Code site and a tool called sendmodem: http://code.google.com/p/iphone-elite/downloads/listSendmodem came with a makefile, a .c source file, and a compiled binary. As a side note: this is the best possible situation for a person like myself. If I can’t find the answers I want in the source I can reverse the binary to look at additional items that get added at build time. If that doesn’t yield the answers I am looking for, I can compile my own version and debug it. Something I found funny was the note of the sendmodem wiki that states this code come from the aSMS app I started out with. The wiki also sent me here (http://www.developershome.com/sms/howToSendSMSFromPC.asp) which provided information on how to send a SMS using AT commands and a cellular modem. And finally the wiki provided me a list of undocumented AT commands (http://code.google.com/p/iphone-elite/wiki/UndocumentedATcommands)With all this information, I started poking around my iPhone. The first thing I wanted to do is see if all the information I had been reading about was still around in the newest v3.0 OS my test phone is running. Nothing would be worse than spending hours on an assumption only to find that the feature you need was removed a few revisions ago. The first thing I tried was using the tty.debug trick to send a text message. I wrote a small ruby script for that:It worked. I then tried to send a test message to my own number. I figured this could be the simplest way to achieve the functionality for fuzzing. However, this didn't work so well. Every time I sent a text message to the same number it originated from the baseband would disconnect and no longer receive text messages until the device get a reboot.After a little over two hours into this exercise, I had a lot of information but a lot more epic fail. I'm the king of Thomas Edison's quote of "I have not failed, I've just found 10,000 ways that won't work". Feeling the path I was on was fruitless, I tried another direction: I looked through the filesystem for anything called "sms". Although I got a lot of hits, but the most interesting thing is "sms.db" in "/private/var/mobile/Library/SMS". Using the "file" command I discovered the database is a SQLite3 database. Since that is a fairly well documented database, and there are tons of tools to view the contents, I copied it off the phone and to my MacBook. The used "SQLite Manager", a Firefox plugin which can be found here: https://addons.mozilla.org/en-US/firefox/addon/5817The sms.db overview and structure as seen in SQLite Manager.The result of the SQL query "SELECT * FROM message"After examining the different tables and data it seems that this is where SMS messages are stored to be later retrieved for viewing and such. Using this as a ending point I can work my way backwards to where the messages come from.Next I enabled syslog debugging, so I can information while sending a SMS message to the device, this should help identify processes that are involved in receiving and processing messages.The last message in the log reads "CommCenter[30]: removing received message 2147483653".CommCenter is involved in receiving and processing SMS messages to some degree. Searching the disk for CommCenter gives a lot of results but one catches my eye: /private/var/CommCenter/spool. The word "spool" looks similar to the Unix "mailspool", and is likely the place to store files that are being sent or received by the device. The spool directory has two subdirectories MobileOrginated and MobileTerminated. Both directories were empty, but if the Unix style spool architecture is being used, temp files will be created as messages are sent and received and removed when no longer needed. I wrote a quick and dirty Ruby script that will monitor the directory and copy any files it finds, even if they live for only a second.Simple Ruby script to check and see if Directory is empty, if not copy the contents to /tmp/I then run the script and send a SMS to the target phone. I get the expected output that a file has been created and moved to /tmp. The file is named r.sms.2147483652The contents of the /private/var/CommCenter/spool/MobileTerminated direcotry.Examining the contents its pretty easy to see that this is the incoming message I sent from another from. I ha the phone number that the message was sent from, the message, and some unprintable characters. I then copied this file off the iphone to my macbook and used hexdump to view the message to see what the unprintable characters are.The text message in hexdump.Doing the same for the MobileOriginated directory got a file called p.sms.58. The structure seems almost the same with the destination phone number and the message surrounded by a few unprintable characters. The message I sent was "What up Homey!"The p.sms.58 message in hexdump.I now know an intermediary point in the SMS delivery process. I attempted to create my own file in the MobileTerminated directory to see if it would be delivered as an SMS message, but no luck. Something is copying the files there then notifying CommCenter there are messages to be processed. The next step was to analyze the CommCenter binary and find any clues on how it operates and where the signal to process messages comes from.I created a tar file of the iPhone filesystem with the command "tar czvf /tmp/fs.tgz /" and let it run. Although this is not the most efficient way to do this (a copy of the tar file is going to end up in the tar file) is it pretty fast. I then used WinSCP to copy the file down to a VMWare Fusion image of Windows XP running on my Macbook. My Windows image has most of my reverse engineering tools, including IDA Pro and HexWorksop. It also has the Windows version of Ruby installed because Ruby is pretty useful for reverse engineering binaries. The fs.tgz file is unzipped with WinRAR and the search for CommCenter begins. CommCenter is located in /System/Library/PrivateFrameworks/CoreTelephony.framework/SupportI loaded the file, selected the CPU (ARM), and configured my analyze options. Although IDA Pro is the best tool for this type of work it sometimes doesn't get everything, so I had to go through the disassembled code and fix a few things. The problems were pretty forward and easily fixed. An example problem was this:This will become more readable like this:After a few minutes of analysis it seems clear that the baseband module receives the message, and then CommCenter reads it using an AT command. At this point we can break testing into two different parts: CommCenter and MobileSMS.CommCenter Testing: Fuzz From SMS.db to MobileSMS UIMobileSMS is the application that handles reading the files from the database and displaying them. Testing MobileSMS is as simple as writing malformed messages to sms.db and then running the SMS application. Well, it would be simple if it wasn't for the database triggers. Trying just to insert a message ends with an error. The is answer is to delete the triggers then recreate them. Here is how to[…]