http://www.willoware.com/docs/Flyer_TheAntiSpec.pdf
This is hilarious - every programmer should take a look at this. Kudos to Benny at Willoware!
Thursday, May 7, 2009
Monday, February 9, 2009
Convergence 2009
Who's coming to Convergence? I'll be there and I hope you all will stop by the Hands-on Labs and say 'hello'.
My friend and fellow MVP Mark Polino will be presenting a fact-filled and fun session - 50 tips in 50 minutes. He's a blast, and his session should not be missed!
I still use the image on his last slide from 'SQL Saturday' as my splash screen. "Microsoft - change the world or go home"
If you copy any .bmp file into the GP folder and name it 'splash.bmp' it will display while Dynamics GP is loading.
Look out New Orleans! GP is coming to town!
Leslie
My friend and fellow MVP Mark Polino will be presenting a fact-filled and fun session - 50 tips in 50 minutes. He's a blast, and his session should not be missed!
I still use the image on his last slide from 'SQL Saturday' as my splash screen. "Microsoft - change the world or go home"
If you copy any .bmp file into the GP folder and name it 'splash.bmp' it will display while Dynamics GP is loading.
Look out New Orleans! GP is coming to town!
Leslie
Problem ascertaining product version
Have you ever launched Dynamics GP Utilities and received the error below?
Error message when you access Microsoft Dynamics GP 10.0 Utilities: "There was a problem ascertaining product version information. Microsoft Dynamics GP Utilities will now exit. Check DUinstall.log for more information"
KB article 952054 discusses the error, but doesn't tell you how to fix it. I've had this come up a couple of times. In both cases the client was attempting their own update. Usually they were changing servers or upgrading to SQL 2005 at the same time.
The fix is in. When you are moving your installation of GP, restore the databases FIRST and then install the software. If you do it the other way around you will get this error message and then it's difficult to diagnose.
Remember - databases first, then application.
I hope this helps someone out there in GP-Land.
Kind regards,
Leslie
Error message when you access Microsoft Dynamics GP 10.0 Utilities: "There was a problem ascertaining product version information. Microsoft Dynamics GP Utilities will now exit. Check DUinstall.log for more information"
KB article 952054 discusses the error, but doesn't tell you how to fix it. I've had this come up a couple of times. In both cases the client was attempting their own update. Usually they were changing servers or upgrading to SQL 2005 at the same time.
The fix is in. When you are moving your installation of GP, restore the databases FIRST and then install the software. If you do it the other way around you will get this error message and then it's difficult to diagnose.
Remember - databases first, then application.
I hope this helps someone out there in GP-Land.
Kind regards,
Leslie
Sunday, January 4, 2009
Year end closing Retained Earnings validation
What's this? Two posts in a single day after weeks of silence? Hopefully this will be helpful for someone out there.
This is for those of you who do 'divisional' closings to Retained Earnings. That's where each 'division' has separate balance sheet and income statement accounts. This is a popular technique when clients want to keep several companies in the same database, yet close out each company to its own retained earnings account.
First of all, you can only (out-of-the-box) differentiate according to a single segment of the chart of accounts. So you can't close by the combination of segment 1 AND segment 2. Also, you need to have created an account for each segment whether or not you need it.
Before executing the close, GP searches through the chart of accounts to make sure you do indeed have a separate retained earnings account for each separate 'division'. The surprise to me was how the software determines whether you're good to go. Instead of looking at the account indexes or separate segment definitions, it looks at the Account Number String field in the Account Index table.
I discovered this last year when one of my clients tried to close and couldn't. Earlier in the year we had removed an unused segment from the chart of accounts (more on that later). The Account Number String field still had a trailing dash "-" left over from the deleted segment. So account number 100-4560-090 read in the field as 100-4560-090- . Once we removed the trailing dash from the field, everything closed beautifully. Go figure.
Another related item. The Account Number String field is used by Integration Manager too. When importing account numbers, you have to use the account separator or the integration will fail. Remember when you could just import the string of characters with no account separator? Not anymore. This was changed a couple of versions ago, so everybody who had strings of characters as the source has probably changed the integration by now.
Gee, and here I thought they created that field so we would no longer have to concatenate segments in reporting.
Enjoy those forms 1099 and W-2!
Leslie
This is for those of you who do 'divisional' closings to Retained Earnings. That's where each 'division' has separate balance sheet and income statement accounts. This is a popular technique when clients want to keep several companies in the same database, yet close out each company to its own retained earnings account.
First of all, you can only (out-of-the-box) differentiate according to a single segment of the chart of accounts. So you can't close by the combination of segment 1 AND segment 2. Also, you need to have created an account for each segment whether or not you need it.
Before executing the close, GP searches through the chart of accounts to make sure you do indeed have a separate retained earnings account for each separate 'division'. The surprise to me was how the software determines whether you're good to go. Instead of looking at the account indexes or separate segment definitions, it looks at the Account Number String field in the Account Index table.
I discovered this last year when one of my clients tried to close and couldn't. Earlier in the year we had removed an unused segment from the chart of accounts (more on that later). The Account Number String field still had a trailing dash "-" left over from the deleted segment. So account number 100-4560-090 read in the field as 100-4560-090- . Once we removed the trailing dash from the field, everything closed beautifully. Go figure.
Another related item. The Account Number String field is used by Integration Manager too. When importing account numbers, you have to use the account separator or the integration will fail. Remember when you could just import the string of characters with no account separator? Not anymore. This was changed a couple of versions ago, so everybody who had strings of characters as the source has probably changed the integration by now.
Gee, and here I thought they created that field so we would no longer have to concatenate segments in reporting.
Enjoy those forms 1099 and W-2!
Leslie
Dex.ini Switches - Part 2
I'm finally getting back to posting. Here's the second installment of the .ini switches. My favorites were posted with part 1, but I'm always on the lookout for more. I've got some for VBA and IM as well.
ADC Processor=TRUE
You will see this line in the Dex.ini file if you are using Manufacturing and have the checkbox marked in ADC Preferences. (dah!)
AdvLookups=FALSE
New Users created will NOT be granted access to the Alternate lookup windows in the SmartList dictionary and will instead be assigned the old ‘green bar’ lookup windows. Very useful if you want to use Dex and try to do a lookup.
AllowBCPTest=FALSE
Prevents utilities from running the BCP test.
AllowWrongDex=TRUE
Will allow Dynamics GP to launch with mis-matched versions of dexterity. DANGER, this is not such a good idea.
ApplicationName=name
Changes the name the runtime engine displays when it is launched. Without this setting the name “Dexterity Runtime” is displayed. With versions 9 and higher this doesn't display very long so it's hard to spot. Hardly worth the effort anymore. It used to be quite fun.
AutoDisplayUpdate=TRUE
Automatically redisplays the process monitor queue.
AutoInstallChunks=TRUE
Causes Dynamics to automatically include the *.cnk file not prompting the user for 'Add New Code' during launch.
BTInterface=NoLoad
This applied to the old Btrieve file handler (PSQL 2000) as to whether the interface would load when Dynamics was launched. Version 7.5 was the last version where PSQL could be used.
Buildphantom=TRUE
Allows creation of a Manufacturing Order for a Finished Good Phantom Item. Sounds spooky.
BuildSQLMessages=TRUE
This one will copy the Dexterity messages to a SQL table on next login and then it will set it back to FALSE. Once in a SQL table the messages can be used in stored procedures. The table is DYNAMICS.dbo.MESSAGES.
DebugFonts=TRUE
This setting causes Dexterity to generate a trace file named "debuglog.txt". This file lists the fonts that were considered and why particular fonts were chosen or rejected. This applies to Report Writer reports.
DebugRW=XXX
Where XXX equals the sum of the values you want to trace from below.
Value = Description
1 = QueryOK Specifies if the report will use a single query or not
2 = Sanscript Logs the run report statement as the Report Writer sees it
4 = RW Query Logs all API calls from RW to the Data Manager
8 = RW Setup If used with RW Run, logs all data returned by Data Manager
16 = RW Steps Logs internal RW steps in processing the report
32 = RW Run Logs all RW runtime calls to the Data Manager
64 = DM SQL Logs internal Data Manager structures and SQL Generation
256 = RW Frames Logs the beginning of each report frame
512 = Tab Delimited Logs output as tab delimited output
Output will appear in a log filed named DebugRW.txt next to the application dictionary.
Example: If you want to log if a report is using a query and the SanScript and SQL code used, then add the following line to your Dex.ini file:
DebugRW=67 (which is 1 + 2 + 64)
To help in trouble shooting problems related to the generation of reports, before printing a report you may choose to mark the Multi-Login Report option on the Report Definition window. This will force the system to perform individual table operations instead of creating a query. If you have the SQLLogSQLStmt = TRUE setting included in your DEX.INI. The individual select statements are then included in your DEXSQL.LOG file and can be analyzed to uncover any potential problems.
DebugUnknownFile=TRUE
Returns a Btrieve or Ctree error code to help track problems with table errors back in the day of Btrieve and Ctree. (version 7.5 and previous)
DexHelpPath=pathname
Path to the Dexterity help files. Consider using this if you want to 'share' help files. This defaults to the application folder on the local client.
Dictionary Version=xx.xx.xxxx
The current version of the Dynamics.dic file. Changing this value will not change the dictionary, but this value is updated when a service pack is installed.
DisplayTableErrors=TRUE, ALL or OPEN
To display an ID for an unknown table error when the Dexterity Database Management Subsystem encounters one. The ID that's displayed can be used to determine the cause of the error.
TRUE – Displays only unknown errors.
ALL – Displays all table errors except the two most common: “duplicate” and “not found”.
OPEN - Displays all table errors for an open operation.
That's all for now. Please let me know if there are any errors in any of the switches so I can be sure to correct the post.
Thanks for "listening"!
Leslie
ADC Processor=TRUE
You will see this line in the Dex.ini file if you are using Manufacturing and have the checkbox marked in ADC Preferences. (dah!)
AdvLookups=FALSE
New Users created will NOT be granted access to the Alternate lookup windows in the SmartList dictionary and will instead be assigned the old ‘green bar’ lookup windows. Very useful if you want to use Dex and try to do a lookup.
AllowBCPTest=FALSE
Prevents utilities from running the BCP test.
AllowWrongDex=TRUE
Will allow Dynamics GP to launch with mis-matched versions of dexterity. DANGER, this is not such a good idea.
ApplicationName=name
Changes the name the runtime engine displays when it is launched. Without this setting the name “Dexterity Runtime” is displayed. With versions 9 and higher this doesn't display very long so it's hard to spot. Hardly worth the effort anymore. It used to be quite fun.
AutoDisplayUpdate=TRUE
Automatically redisplays the process monitor queue.
AutoInstallChunks=TRUE
Causes Dynamics to automatically include the *.cnk file not prompting the user for 'Add New Code' during launch.
BTInterface=NoLoad
This applied to the old Btrieve file handler (PSQL 2000) as to whether the interface would load when Dynamics was launched. Version 7.5 was the last version where PSQL could be used.
Buildphantom=TRUE
Allows creation of a Manufacturing Order for a Finished Good Phantom Item. Sounds spooky.
BuildSQLMessages=TRUE
This one will copy the Dexterity messages to a SQL table on next login and then it will set it back to FALSE. Once in a SQL table the messages can be used in stored procedures. The table is DYNAMICS.dbo.MESSAGES.
DebugFonts=TRUE
This setting causes Dexterity to generate a trace file named "debuglog.txt". This file lists the fonts that were considered and why particular fonts were chosen or rejected. This applies to Report Writer reports.
DebugRW=XXX
Where XXX equals the sum of the values you want to trace from below.
Value = Description
1 = QueryOK Specifies if the report will use a single query or not
2 = Sanscript Logs the run report statement as the Report Writer sees it
4 = RW Query Logs all API calls from RW to the Data Manager
8 = RW Setup If used with RW Run, logs all data returned by Data Manager
16 = RW Steps Logs internal RW steps in processing the report
32 = RW Run Logs all RW runtime calls to the Data Manager
64 = DM SQL Logs internal Data Manager structures and SQL Generation
256 = RW Frames Logs the beginning of each report frame
512 = Tab Delimited Logs output as tab delimited output
Output will appear in a log filed named DebugRW.txt next to the application dictionary.
Example: If you want to log if a report is using a query and the SanScript and SQL code used, then add the following line to your Dex.ini file:
DebugRW=67 (which is 1 + 2 + 64)
To help in trouble shooting problems related to the generation of reports, before printing a report you may choose to mark the Multi-Login Report option on the Report Definition window. This will force the system to perform individual table operations instead of creating a query. If you have the SQLLogSQLStmt = TRUE setting included in your DEX.INI. The individual select statements are then included in your DEXSQL.LOG file and can be analyzed to uncover any potential problems.
DebugUnknownFile=TRUE
Returns a Btrieve or Ctree error code to help track problems with table errors back in the day of Btrieve and Ctree. (version 7.5 and previous)
DexHelpPath=pathname
Path to the Dexterity help files. Consider using this if you want to 'share' help files. This defaults to the application folder on the local client.
Dictionary Version=xx.xx.xxxx
The current version of the Dynamics.dic file. Changing this value will not change the dictionary, but this value is updated when a service pack is installed.
DisplayTableErrors=TRUE, ALL or OPEN
To display an ID for an unknown table error when the Dexterity Database Management Subsystem encounters one. The ID that's displayed can be used to determine the cause of the error.
TRUE – Displays only unknown errors.
ALL – Displays all table errors except the two most common: “duplicate” and “not found”.
OPEN - Displays all table errors for an open operation.
That's all for now. Please let me know if there are any errors in any of the switches so I can be sure to correct the post.
Thanks for "listening"!
Leslie
Subscribe to:
Posts (Atom)