Friday, March 28, 2008
10:46 AM | 
Posted by
David E. Patrick
MES (from the GP public newsgroups) had an error when attempting to use Integration Manager:
"Operation must use an updateable query"
I love these kind of error messages, because they're just so darn recognizable. (I'm not kidding, really, its quite sad when you can recognize error messages, like, "Hey, there's Larry!")
I instantly recognized this to be an Access database error that occurs usually for one of two reasons (actually its the same reason, the database cannot be written to, but there's two different causes).
The first cause is if the Access .mdb file has been marked with the readonly attribute. This can happen when you copy it from a CD or if you inadvertly had it selected when you selected another file and marked it for read only.
The second cause (and more common, I think) is if you don't have permissions to write to the database, which was the case for MES.
Which Access database file am I referring to? The IM.mdb file that Integration Manager uses to store its integration definitions.
So, if you get this error when trying to run an integration, make sure that the user who you are logged in as when trying to run the integration has permissions to write to the IM.mdb file!
If that aint it, make sure the file hasn't been marked read only.
Happy Integrating!
"Operation must use an updateable query"
I love these kind of error messages, because they're just so darn recognizable. (I'm not kidding, really, its quite sad when you can recognize error messages, like, "Hey, there's Larry!")
I instantly recognized this to be an Access database error that occurs usually for one of two reasons (actually its the same reason, the database cannot be written to, but there's two different causes).
The first cause is if the Access .mdb file has been marked with the readonly attribute. This can happen when you copy it from a CD or if you inadvertly had it selected when you selected another file and marked it for read only.
The second cause (and more common, I think) is if you don't have permissions to write to the database, which was the case for MES.
Which Access database file am I referring to? The IM.mdb file that Integration Manager uses to store its integration definitions.
So, if you get this error when trying to run an integration, make sure that the user who you are logged in as when trying to run the integration has permissions to write to the IM.mdb file!
If that aint it, make sure the file hasn't been marked read only.
Happy Integrating!
Thursday, March 27, 2008
So, a user by the name of 2020 asked on the newsgroups the other day, how can we disable outlook on the Great Plains home page?
I happen to have had this same issue and using my trusty SQL Profiler, I found that when I manually uncheck Outlook from my home page, GP ran a SQL statement like the following :
UPDATE DYNAMICS.dbo.SY08100
SET Visible = 0
FROM DYNAMICS.dbo.SY08100
WHERE COLNUMBR = 1
AND SEQNUMBR = 3
AND Visible = 1
AND USERID = 'dpatrick' -- comment this if you want to do it for all users
AND SectionID = 2
This works great, but it doesn't actually stop any particular user re-checking Outlook on the home page (but it got me what I wanted, which is to default Outlook to being off for everyone).
Dave Musgrave, from Microsoft, later chimed in and gave us this link:
https://mbs.microsoft.com/knowledgebase/KBDisplay.aspx?scid=kb;en-us;918313
which discusses how to actually disable Outlook from the homepage (and uses a script that looks pretty close to the one I use).
Good stuff!
Thanks Dave and thanks 2020 for asking the question!
I happen to have had this same issue and using my trusty SQL Profiler, I found that when I manually uncheck Outlook from my home page, GP ran a SQL statement like the following :
UPDATE DYNAMICS.dbo.SY08100
SET Visible = 0
FROM DYNAMICS.dbo.SY08100
WHERE COLNUMBR = 1
AND SEQNUMBR = 3
AND Visible = 1
AND USERID = 'dpatrick' -- comment this if you want to do it for all users
AND SectionID = 2
This works great, but it doesn't actually stop any particular user re-checking Outlook on the home page (but it got me what I wanted, which is to default Outlook to being off for everyone).
Dave Musgrave, from Microsoft, later chimed in and gave us this link:
https://mbs.microsoft.com/knowledgebase/KBDisplay.aspx?scid=kb;en-us;918313
which discusses how to actually disable Outlook from the homepage (and uses a script that looks pretty close to the one I use).
Good stuff!
Thanks Dave and thanks 2020 for asking the question!
Tuesday, March 18, 2008
Neil Jordan shot me an email about one of my recent posts and mentioned that it would be nice to have a central place to discuss GP Developer related issues.
I agreed that it would be nice to have a central depot for sharing GP developer information.
The challenge I find is that there already are several "central" places to share info, and the fact that there are several of them kind of takes away from any of one of them being the "central" one!
That said, here's my short list of GP dev resources:
If I had to pick one to be the grand daddy central place, it'd have to be the GP newsgroups (but there really are 2 of them that I check, so I guess I still can't pick just one, ack!).
The nice thing about the newsgroups is that they are read and answered by MS folks and (even better) by MVPs. So, it's not a bad place to voice your concerns, share your issues, and sometimes even help your fellow GP dev guy out.
Do you have any resources to add to my list? Maybe we need a central list of GP dev resources? Maybe a wiki or something?
What do you think?
Wednesday, March 5, 2008
I mentioned yesterday that I had to restore some Item records after making a horrendous change to one of my Unit of Measure Schedules. It occurred to me that not everyone may be familiar with the underlying GP tables, maybe because they are named oh-so-intuitively...NOT!
So, for those of us who can't read minds, here's two ways for finding out what the table IV00106 really is. From the GP Menu, select:
Tools >> Resource Descriptions >> Tables
That pops up the Table Descriptions window. From there you can click the elispes to select a table.
Once you select a table, you get the down and dirty details.
Another way, which is actually the way I use most of the time, simply because it's a quick and dirty look up using SQL in Query Analyzer (or SQL Server Management Studio, as it's now called, but I still like the old name) , which is where I am at most of the day. So, without further ado, here's the script:
SELECT *
FROM DYNAMICS..SY40501
Gives you all the physical table names, what series they belong to, and a little descriptive info on what the table actually contains.
While the first way to obtain table info (i.e. through the GP GUI) certainly gives a more complete picture, the second way (i.e. through SQL) usually gives me what I am looking for.
Have fun!
Tuesday, March 4, 2008
So....
I made a change to one of my Unit Of Measure Schedule's yesterday, trying to figure out why one of my items didn't have a unit of measure showing in one of our custom web pages that query from the Great Plains database. Turns out that the item's default purchasing unit of measure was left blank and that was the culprit, because that's the field that our custom web app displays.
But, in my debugging efforts (and yes, I *know* I shouldn't have been messing around in the production environment, yes - we have test and QA and DEV environments, any one of which would have been a better choice to experiment in, BUT I didn't think my change was going have to be saved (where are you UNDO?!?!) and I didn't think the change to my UoM Schedule would result in the deletion of records from three different tables! Yes, the change I made, after saving, caused about 16000 records to be deleted from each of 3 IV tables. Eeeks!
Yes, Great Plains did warn me, something along the lines of "your price list and options will be lost", but who pays attention to that stuff. :-)
Ah well, lessons learned. I had to do a restore from the night before (thank God for my back ups, which I test almost too much) and copy all my deleted records from the following three tables:
IV00106 - Item Purchasing Options
IV00107 - Item Price List Options
IV00108 - Item Price List
So, just a little drama and no permanent damage done (I hope!).
The moral for today is, be careful what you tinker with in Great Plains, sometimes it wont let you out without saving (see my earlier post/rant) and sometimes what seems like a small change can result in big changes!
Sign up to get 40% off new exams on Visual Studio 2008 and SQL Server 2008!
http://www.microsoft.com/learning/mcp/sqlvs/offer/default.mspx
http://www.microsoft.com/learning/mcp/sqlvs/offer/default.mspx
Subscribe to:
Posts (Atom)
