Today’s #TipTuesday post is around GP Utilities and what permissions are required. If you are going through any service pack install or upgrade, you might have a lot of workstations that need to be updated! In our case, we just upgraded our Dynamics GP and wanted all hands on deck to help with installs, including some IT team members who didn’t have any GP access. Here’s how you do it and what permissions are required.
Today’s #TipTuesday post is for anyone who might be running more than one local instances of SQL Server. I often have at least a couple of instances on my laptop, as historically I would want to have the ability to mimic some client installs, as close as I can. While I am no longer a consultant, I will continue to do this so that I can have an instance the somewhat resembles what version of SQL and Dynamics GP we use at work + the latest version of GP with all the latest things installed. For blogging alone, I want to have the latest and greatest to play with and learn what’s new.
Today’s #TipTuesday is around the permissions required for either creating reports or publishing reports in SSRS. These are permissions as they relate to Report Builder 3.0 at least, as I haven’t tested that the exact same is true via Business Intelligence Development Studio (BIDS). I assume the same applies but haven’t tested that myself so YMMV.
Also of note: this article is purely on the permissions required in SSRS itself, I am not touching on the data side but obviously the users who are previewing data here will also require the correct access to the data depending on what your data sources are.
Today’s #TipTuesday has been on my list for a while and it’s a great resource that many people don’t know exists.
Microsoft has creating a “living” document that has embedded links to SQL views that you can run and tweak in your own Dynamics GP environment to create custom smartlists with. The document says it is for Smartlist Designer but the reality is if you create these SQL views, you can also use them in eOne’s Smartlist Builder if you have the product instead.
Today’s #TipTuesday is not an application tip but a technical one.
Most Dynamics GP clients have one or more test companies or test environments. I’d be willing to wager that many have some standard scripting that is run when a test company is refreshed and may even automate it in a SQL stored procedure or job. There are at least 2 standard Microsoft scripts that should be run all the time: changing the db_owner to ‘DYNSA’ and the standard script to update company database references in the refreshed company db.
Today’s story starts with a SQL trigger, and a Dynamics GP service pack which dropped the trigger, unbeknownst to me. Fortunately, I had planned ahead, not wanting to rely on my (or anyone’s) memory to remember to check for issues after installing service packs!
A few months ago, I had posted about the issue that led to this particular trigger in the first place. The short version is its sole purpose is to correct an issue in Dynamics GP that may or may not be a bug! This post is less about why the trigger exists in the first place and more about how to identify when a trigger has been dropped from a table.
Recently, a client was starting a SafePay & EFT implementation for Dynamics GP and one of the requirements of the bank was that the vendors cannot have any special characters outside of a handful of “regular” special characters. Their specifications and instructions had a list of acceptable characters and a longer list of unacceptable characters.
Continue reading “Looking for special characters in SQL”