Great Plains Dexterity Dynamics eEnterprise Microsoft CRM Microsoft RMS Crystal Reports SQL .Net C# International Chicago Illinois Customizations Great Plains Programming Development Offshore Programming FRx ReportWriter Integration Manager POS Upgrade Data Recovery Conversion EDI Barcoding SQL Multicurrency Microsoft Business Solutions Great Plains Certified Master FAQ Forum Continuum for VB Btrieve Ctree Pervasive SQL.2000 Great Plains Business Portal eOrder eView eRequisition Intellisol Kampdata Mekorma Horizon Wennsoft Naperville Schaumburg Lombard Hinsdale Aurora Rockford Downers Grove Brazil Moscow Montreal Mexico USA Canada California

Issue

I am receiving the following error message within Dynamics Utilities - "An error occured while using the BCP utility -- data was not correctly copied to the server. Please verify your ODBC settings and that BCP has been correctly installed." What can I do to get around this error message.

Resolution

Use the following checklist to troubleshoot the possible reasons BCP can fail:

1. Verify that your ODBC connection is using SQL server authentication. Only using Windows authentication will cause BCP to fail.

2. Check the TestBCP.bcp document found in the Great Plains directory to determine what is causing BCP to fail.

3. Add AllowBCPTest=FALSE to the Dex.ini file and launch Utilities.

4. On SQL Server, BCP will fail if the Servername is not the same as the Machine Name or if the Servername contains illegal characters. Determine the SQL Server Servername by executing the following statements against the MASTER database in Query Analyzer:

SELECT @@servername

SELECT * from master..sysservers

5. If the scripts in Step 4 do not match, you will want to change the SQL Servername using the following steps:

From the SQL Query Analyzer window, execute the following statements one at a time against the MASTER database. The Servername for the sp_dropserver is the wrong name and the Servername for the sp_addserver is your computer name:

sp_dropserver 'WrongSERVERNAME'

sp_addserver 'RightSERVERNAME', local

Once the above statements are executed, stop and start Microsoft SQL Server for the changes to take effect.

Run SQL Server Setup from the original product CD. Go as far as the Typical, Minimal, and Custom screen. Doing so will not reinstall SQL Server or any components; however, it will update SQL Server internally to reflect the Windows computer name.

6. If the scripts in Step 4 do match, check the SRVID for the Servername. It needs to be 0, which tells the system it is the local server. Step 5 will make the server local if the SRVID is not 0.

7. Verify that the path to BCP.EXE is correct, that there is only one BCP.EXE, and it is the correct version of SQL that you are using. To verify the path to BCP.EXE, go to the DOS prompt and type PATH and you should see the path to the MSSQL7 | Bin directory for SQL 7.0 or Program Files | Microsoft SQL Server | 80 | Tools | Bin directory for SQL 2000 that holds the BCP.EXE file. If there is more than one BCP.EXE and they are different versions, rename the BCP.EXE of the version that you are not using.

8. Check the ODBCBCP.DLL and SQLSRV32.DLL files. The ODBCBCP.DLL and SQLSRV32.DLL files must be the same version. If they are different versions, rename the SQLSRV32.DLL file and reinstall MDAC(ODBC). The ODBCBCP.DLL and SQLSRV32.DLL files can be found in Windows Explorer under the WINNT | System32 folder. They must be exactly the same (ODBCBCP.DLL = 3.70.0623 and SQLSRV32.DLL = 3.70.0820 will not work).

9. Change the 'sa' password if it contains spaces or symbols. Examples: &, *, #, or %.

Using Enterprise Manager, reset the 'sa' password to something that is just alphanumeric characters.

10. Check ODBC connectivity:

Verify that the System DSN tests successfully.

If you are using SQL Server 7.0, verify that you can successfully run odbcping:

(Odbcping - D Datasource -U Username -P Password)

Set up a new System DSN with a name that have not been used before.

11. The Error Messages Master (SY01700) table is the first table populated within DYNAMICS database via BCP during the eEnterprise/Dynamics for SQL ClientInstallation. Verify that BCP is failing by checking the number of records in the Error Messages Master table. Run the following statement against the DYNAMICS database in Query Analyzer:

SELECT * from DYNAMICS..SY01700

If there are no records in the SY01700 table, the BCP process failed. Proceed with the checklist.

12. Verify that no errors exist in the SYSDATA.BCP file. This file can be found in Windows Explorer under eEnterprise | SQL | System | Data. To open this file, double-click on the SYSDATA.BCP file and check for error messages.

13. BCP will fail if the Global Variables in the SYSDAT.BAT file are not populating correctly. To run the BCP manually:

In Windows Explorer, go to the eEnterprise | SQL | System | Data folder. Locate SYSDAT.BAT, right-click on it and make a Copy of the file in the same directory. Once the copy has been made, right click on the file and select Edit. This file should open in Notepad.

Do a Replace (Find | Replace) and Find - replacing the following values:

Find: %SERVER% Replace with: the SQL Server name

Find: %USER% Replace with: sa

Find: %DATABASE% Replace with: DYNAMICS

Find: %PASSWORD% Replace with: the sa password

(if none, just delete the %PASSWORD% text and leave it blank)

Save the file and close. Double-click on the Copy of SYSDAT.BAT. A DOS window should appear. Once the DOS window closes, run the following query against the DYNAMICS database in Query Analyzer to verify that the BCP was successful:

SELECT * from DYNAMICS..SY01700

Issue

When trying to Launch Dynamics 6.0 or 7.0, the error message MEM_BAD_HANDLE appears. The error does not occur on every workstation and will sometimes work on a workstation, and then not work the next time the application is launched. I have tried to shutdown the Pervasive.SQL 2000 service and restart without success.

Resolution

1. The first thing to try to resolve this error is to rename the Reports.dic that this workstation is looking at. You can verify which Reports.dic it is using by going to Setup - System - Edit Launch File. Once there, highlight the product of Dynamics and the path to the Reports.dic should appear at the bottom of the window. If you cannot get into Dynamics, you can right click on the Dynamics.set file on this workstation and choose edit. This will also allow you to see the path for the Reports.dic.

2. If renaming the Reports.dic does not solve the problem, you will need to reinstall the Dynamics application into a new directory on the workstation. You will first want to do an unistall of the application. Delete the original application directory, and then reinstall the application. The reason that you need to do an install into a new directory is because the uninstall does not remove all files from the application directory. If you reinstall, you will use the same files from the original application install and the error may still occur.

Issue

How to set up the ODBC Data Source for Great Plains on Microsoft SQL Server 2000 and 7.0?

Resolution

To set up an ODBC Data Source connection for SQL Server using the ODBC Data Sources, follow the steps below:

2. Verify that your SQL Server ODBC driver is Version 3.70 for SQL 7.0 and 2000.80 for SQL 2000 by selecting the Drivers tab and locating SQL Server in the list.

3. Go to the System DSN tab and click Add button to create a new ODBC.

4. Choose the SQL Server and click Finish.

5. Provide an ODBC name, description, and enter the name of the SQL Server as the server to which it will be connecting to and press Next.

Name...........Enter the name you want to use for the data source. This name will be stored in the ODBC.INI file. Use the same name for the 32-bit ODBC data source for Dynamics for all clients and process servers.

Description....Enter a description of the data source.

Server..........Enter the name you assigned to the SQL Server when you installed Microsoft SQL Server.

6. Switch the radio button to use SQL Server authentication, then connect to SQL Server as 'sa', and use the 'sa' password. Click Client Configuration button.

7. On the left side under Network Libraries, choose TCP/IP from the list. Verify that the Server name appears in the Server alias and Computer name boxes. Verify that the Dynamically Determine Port box is unchecked and the Port number is 1433, if you kept the Default Instance during the install of SQL Server. Click OK. When you get back to the above screen, click Next.

Note: If named instances of SQL Server are installed, a unique Port Number is recommended for each SQL instance.

8. Uncheck all the boxes, do not change the default database even if you will be using this ODBC for only one company. Click Next.

9. Uncheck all the boxes. Click Finish.

10. Verify all the information below, then click Test Data Source.

11. Click OK, if the test has completely successfully, and click OK on the above screen to complete the ODBC setup. If it comes back with an error at this point, make sure you can ping your server, and if you can, follow the steps above again.

Issue

A Regular User or Anonymous User account may fail to run an application within a Citrix ICA session. For anonymous published applications that are failing, typically a User account also fails. Making the User class part of the local and/or Domain Administrators group usually grants the User account sufficient rights to successfully execute the application. This often means that there is a file rights issue on the server(s) in question. What process can I use to audit the rights determining where insufficient rights exist?

Resolution

Please follow the steps below to resolve these types of issues:

Verify what happens with the particular User account at the server console. If the error appears at the console level, the problem is most likely with the application itself. Ensure the error can be corrected on the console before continuing.

Add the User to the local and/or Domain Administrator group. Retest the account at the console. If the application executes, move to Step 3. If the application still fails to execute, it is more likely an application configuration problem.

Log on to the server as an administrator.

If the Citrix server giving the error is a domain controller, only a Domain account can log on (there are no local accounts). If the Citrix server giving the error is a standalone server, log on to the server as a local administrator.

If the Citrix server giving the error is a member server in a domain, select the local server name in the drop down box for the server at the Logon prompt.

Enable auditing in User Manager for Domains. From the Policies Menu choose Audit. Typically it is enough to select File and Object Access for failure.

Audit the directory of your choice; %systemroot%is a good start and is most commonly the problem. Begin by right clicking the directory, selecting Properties, Security, Auditing. Add the name of the user to be audited. Check both the Replace Auditing on Subdirectories and Replace Auditing on Existing Files boxes. Also, check off all failures to be audited. Press OK.

If you receive an error message that the Pagefile.sys cannot be audited, press OK.

You may receive one of the following error messages when setting up auditing on the directory of choice: "The current Audit Policy doesn▓t have auditing turned on. Ask an Administrator to use User Manager to turn on auditing."

If this error is displayed, ensure that auditing is enabled for the local SAM database via the domain SAM in User Manager for Domains.

Connect to the server desktop as an administrator, open the Event Viewer, and select the Security Log.

With a second session to the server desktop, make a "duplicate" copy of a custom ICA connection if needed. Connect with the name of the user you are auditing.

10.

When the user has a desktop, delete any entries in the Security Log.

11.

Execute the application and acknowledge any error messages.

12.

Recheck the Security Log for any new entries. Choose View and then Refresh if needed.

13.

Double-click each logged entry (there only should be a few). Note the file path and subsequent dll and exe files. Check the permissions on each file. Locate the file to which the user does not have access and is causing the failure.

Adding the domain users group with Read permissions usually resolves the issue.

NOTE: These steps may need to be repeated for different applications or subsequent errors within the same application.

SYMPTOM

"The Account Format is not set, please launch Utilities to synchronize the Account Framework." error message occurs when i try to launch Dynamics. When Utilities is launched, I still receive the same error.

RESOLUTION

This error can occur for a variety of reasons. Some of the procedures that have resolved this problem are:

1. Change Synchronize to FALSE in the Dex.ini located within the Dynamics directory on the local workstation.

2. If other workstations are working:

a. Copy a Dynamics.dic from the Dynamics directory on a working workstation.

b. Or, uninstall Dynamics from the workstation and reinstall the Dynamics code on the workstation.

3. If an update from Dynamics 4.0 to 5.0 has recently been completed, there may be an old Forms.dic interrupting the process. The Forms.dic does not update from Release 4.0 to 5.0. It needs to be renamed and the modified forms it held need to be recreated entirely. After renaming the file, you should be able to launch Dynamics successfully without this error.

4. If a new installation of Dynamics is being performed, this error can occur if an account framework has been chosen that is too short for the Lesson company (Two, Inc.). The Lesson Company▓s account framework is 3-4-2. If the account framework chosen during the installation utilizes segments shorter than 3-4-2, this error will occur.

SYMPTOM

What is the format for the UNC pathname?

RESOLUTION

The UNC pathname must use the following syntax:

\server

The server is the name of the shared server.

The sharename is the name used to share the server.

Dynamics is the directory where the Dynamics is stored on the server.

For example, if your Dynamics data is stored on a server titled Server1 and the sharename is User, the UNC pathname would be \Server1.

SYMPTOM

What is the format for the UNC pathname?

RESOLUTION

The UNC pathname must use the following syntax:

\server

The server is the name of the shared server.

The sharename is the name used to share the server.

Dynamics is the directory where the Dynamics is stored on the server.

For example, if your Dynamics data is stored on a server titled Server1 and the sharename is User, the UNC pathname would be \Server1.

Printer Problems Checklist

1. Try printing from the LESSON Company. If it prints fine, delete the modified report and recreate it.

2. If it is a modified report:

A. Try removing security and print the original report.

B. Try moving the REPORTS.DIC (temporarily) and try printing again.

C. Recreate the REPORTS.DIC file. Refer to TechKnowledge Document ID 18700 - How to recreate my REPORTS.DIC file in Release 6.0 and 7.0?.

3. Reinstall the printer driver. It may be corrupt. Try a newer or even older printer driver

4. If the printer is on the network, try connecting locally to the workstation and try printing again.

5. Try checking the vertical alignment settings of your printer.

6. If using a dot matrix printer, try a different emulation. For example, if it is an Okidata printer, change the setting on the printer to Epson then try a different printer driver.

7. If the problem is with a postscript laser printer, try using a pcl driver. If there is a problem with pcl, try postscript.

SYMPTOM

Unable to run VBA from a remote Dynamics/eEnterprise client that is running on Citrix server.

RESOLUTION

The Citrix user for which you are logged in does not have the correct rights or is missing Dynamics VBA registry entries/initialization files. When installing in a Citrix/Terminal Server environment, you must be in install mode to install Dynamics/eEnterprise with VBA. If you are not in install mode, the registry entries/initialization files are not updated with the correct permissions

Issue

Error - 'Lesson Company failed to initialize' occurs when installing the TWO Company during an eEnterprise installation.

Notes

1. The Dynamics database installed without errors.

2. The SY01700 has been checked against the Dynamics database and it is empty.

3. The server name matches the computer name and there are no symbols or spaces in either one.

4. I have followed TechKnowledge 21167 and TechKnowledge 18256, but the SY01700 table still will not populate.

Resolution

1. Check your 'sa' Password. Verify that it does not have any spaces or symbols. If it does, change your 'sa' Password so that it doesn't have any symbols or spaces.

2. Go through TechKnowledge 18256 again to populate the SY01700 table.

3. Reinstall the TWO Company.

You can also check the following:

1. Did you create an ODBC data source that is using SQL Server Authentication and are logging in as 'sa' with the appropriate Password (if applicable)?

2. Can you ODBCPING the SQL Server?

3. Stop and start the SQL Service.

4. Reboot the SQL Server.

Issue

I am trying to add a service pack and get the error message

stating that I have a privilege error. The error happens right

after I tell it to include new code. I have tried logging in

as ADMIN and a user with administrative rights. What is causing

this error?

Resolution

Verify that the chunk file is not flagged as read only. You can

do this by right clicking on the chunk file, and choosing

PROPERTIES. If the read only box has a check mark in it, uncheck

and launch to try to include new code again. The error should

not occur now, and your new code should be incorporated.

Issue

During Utilities, Dynamics receives the error message - The stored procedure versionIsCurrent() of form duSQLInstall Pass Through SQL returned the following results: DBMS: 208, Dynamics: 0. What is causing this?

Resolution

A DYNAMICS Database has already been created in Enterprise Manager. If a DYNAMICS database exists during a new install this error will result. Remove the DYNAMICS database and launch Utilities again.

Issue

Invalid User Error occurs testing the connection when trying to set up an ODBC connection to my SQL 2000 Server. I am setting it up to use SQL Authentication. I enter 'sa' as the user, and enter the correct 'sa' password.

Note - It was verified that 'sa' exists in SQL 2000 and the passwords entered is correct.

Potential Cause

SQL 2000 was installed using NT (Windows) Authentication. Mixed mode (SQL Server and Windows) should have been used during the install.

Resolution

Change the Authentication mode to the supported Authentication.

1. Log into Enterprise Manager as 'sa'.

2. Expand the tree in Enterprise Manager until you see the SQL Server.

3. Right-click on the SQL Server and select Properties.

4. Click on the Security tab.

5. Change the Authentication mode from NT Authentication to SQL Authentication.

6. Restart the SQL 2000 Server.

SUMMARY

How to transfer my existing Great Plains on MSDE install to a brand new server and maintain my Great Plains users and data?

MORE INFORMATION

NOTES

1. If you are running Microsoft SQL Server and want to transfer Great Plains to a new Microsoft SQL Server machine, refer to TechKnowledge 7132 for instructions.

2. If using FRx, refer to TechKnowledge 23351 for steps to move FRx to another server.

Here are the steps to recreate your setup at a new server:

1. Install MSDE 2000 SP3 on the new server with the same sort order as the old server using the MSDE 2000 SP3a CD shipped with Great Plains Standard.

You can find your sort order by running the following script in the Support Administrator (SA) Console against your Master database:

sp_helpsort

2. Using the SA Console, execute the Capture_Logins_MSDE script against the DYNAMICS database on the old server.

Capture_Logins_MSDE

3. Make a backup of the DYNAMICS database and Company databases on the old server.

3.1. Go to File | Backup

3.2. Select the System database (DYNAMICS Database)

3.3. Select the backup directory

3.4. Select Backup

3.5. Repeat for each company database

3.6. As an alternative, you can run the following script in the SA Console:

BACKUP DATABASE TWO

TO DISK = 'C:Plains.bak' WITH INIT

Make the following changes to the statement above:

TWO = your database name to backup

FROM DISK = fill in the correct path for the backup filename

Note: The above backup script will overwrite if a file already exists in that backup

location.

4. Copy the backup file from the old server to a local drive on the new server where Microsoft SQL Server is installed.

5. Set up an ODBC connection to point to the new server at the new server and all client workstations that have Great Plains Standard installed. If assistance is needed, refer to TechKnowledge 6733.

6. At the new server, install a CLIENT/SERVER installation of Great Plains Standard and create a new DYNAMICS database by using Great Plains Utilities - be sure to use the same Account Framework as before. If you are unsure, execute the following script in the Support Administrator Console to determine the Account Framework:

select * from DYNAMICS..SY003001

select * from DYNAMICS..SY00302

MXLACNUM in the SY003001 = the maximum account length

MXNUMSEG in the SY003001 = the maximum number of segments

SGMNTLTH in the SY00302 = the maximum length of each segment

7. Create the new Company database(s) on the new server with the same DB/Company ID and Company Name using Great Plains Standard Utilities.

8. In Great Plains Standard, restore the DYNAMICS database and each Company database backup file created above in Step 3. To do this, you must follow the instructions below:

8.1. Go to File | Restore

8.2. Select the System database (DYNAMICS database).

8.3. Select the backup file.

8.4. Select OK.

8.5. An Alternative is to restore via the script below:

RESTORE DATABASE [TWO]

FROM DISK = 'C:Plains.bak' WITH FILE = 1, NOUNLOAD,

STATS=10, RECOVERY

Make the following changes to the statement above:

TWO = your database name to backup

FROM DISK = fill in the correct path for the backup filename

NOTE: If the location of the database files are different on the new server from the old

server, refer to the following steps to restore a backup from one server to another server if

the database file locations are different. For example, if on the old server the database files

where located at D:FilesSQL Serverand on the new

server the location is C:FilesSQL Server,the following

procedures would need to be executed to restore the backup.

8.1. The following script must be executed in the Support Administrator Console with

the appropriate changes from step b through e.

RESTORE DATABASE [TEST]

FROM DISK = N'C:Files\par TWO_Mar5-2003.bak'

WITH FILE = 1, NOUNLOAD,

STATS = 10, RECOVERY, REPLACE,

MOVE N'GPSTWODat.mdf' TO N'C:FilesSQL

Server.mdf',

MOVE N'GPSTWOLog.ldf' TO N'C:FilesSQL

Server.ldf'

b. Next to RESTORE DATABASE, change TEST to be the name of your company on the new server.

c. The path following FROM DISK will be the physical path to the backup file. Verify it is correct.

d. The first MOVE section specifies the location of the .MDF file. Change the

first .MDF file following MOVE to be the .MDF filename of the database.

Following TO, enter the physical path to the .MDF file of the database on the

NEW server. In this example, the database is TEST and the .MDF file is location

on the new server is C:FilesSQL Server.

e. The second MOVE section specifies the location of the .LDF file. Change the

first .LDF file following MOVE to be the .LDF filename of the database.

Following TO, enter the physical path to the .LDF file of the database on the NEW

server. In this example, the database is TEST and the .LDF file is location on

the new server is C:FilesSQL Server.

9. Repeat Step 8 for each database.

10. Usine the SA Console, execute the Drop_User_DYNAMICS_MSDE script against the DYNAMICS database on the new server. This script is for both SQL 7.0 and SQL 2000.

Drop_User_DYNAMICS_MSDE

11. Using the SA Console, execute the Drop_User_Company_MSDE against each of your COMPANY databases on the new server. This script is for both SQL 7.0 and SQL 2000.

Note You will need to replace %Companydb% with your Company database name for this script.

Drop_User_Company_MSDE

12. Using the SA Console, execute the Create_SQL_Logins_MSDE.sql script against the DYNAMICS database on the new server.

Create_SQL_Logins_MSDE

13. Using the SA Console, execute the Add_Users_Company_MSDE against each of your COMPANY databases on the new server. This script is for both SQL 7.0 and SQL 2000.

Note You will need to replace %Companydb% with your Company database name for this script.

Add_User_Company_MSDE

14. Using the SA Console, execute the GRANT70.SQL (SQL 7.0 & SQL 2000) script against the DYNAMICS and ALL COMPANY databases on the new server.

GRANT70.SQL

15. Load any third party products or additional products (such as Human Resources and Fixed Assets, etc.) that are needed at the new server.

16. If the Reports and Forms dictionaries were shared on the old server, move them to the new server. You can verify if the Reports and Forms were shared in the Dynamics.set file on a client workstation where Great Plains is loaded. Right-click the Dynamics.set file and choose Edit.

REFERENCES

1. Refer to TechKnowledge 32985 - How to Install the Support Administrator Console

2. If you are running Microsoft SQL Server and want to transfer Great Plains to a new Microsoft SQL Server machine, refer to TechKnowledge 7132 for instructions.

3. If using FRx, refer to TechKnowledge 23351 for steps to move FRx to another server.

Question

When I log into eEnterprise 5.5, I get this message that says: You Must Upgrade Using eEnterprise Utilities. I upgraded from awhile ago, but I have not seen this problem before. What do I need to do so I can log in again?

Answer

Someone has used a lower version of eEnterprise client to log on to the system. This has changed some tables in SQL, and now eEnterprise thinks it's on a previous version.

1. Run the following query against the DYNAMICS database in Query Analyzer:

select * from DYNAMICS..DU000020

2. Find the entries in the versionMajor and versionMinor columns that do not match the version you are using, for example if you are on eEnterprise 5.5, your versionMajor should be 5 and versionMinor column should be 50. You will want to note the one that corresponds with the correct versionMajor and versionMinor number.

3. You will need to change the versionMajor and versionMinor columns that do not match the version you are using. To do this, you will need to run an update statement in Query Analyzer against the DYNAMICS database (you may have to modify this if you have another companyID which has a different versionMajor and/or versionMinor). Refer to example for syntax which is written based on eEnterprise 6.0:

update DYNAMICS..DU000020 set versionMajor = 6 versionMinor = 0

4. Check one other table to see if you have any differing values in Query Analyzer against the DYNAMICS database.

select * from DYNAMICS..DB_Upgrade

5. If any values differ in this table, you will need to run an update statement to update this table. Refer to example for syntax which is written based on eEnterprise 6.0:

update DYNAMICS..DB_Upgrade set db_verMajor = 6, db_verMinor = 0, db_verOldMajor = 6, db_verOldMinor = 0

Run Step 1 and Step 4 again to make sure all companies are on the same version majors and minors. Then log back into eEnterprise. You may want to remove all version of eEnterprise clients that are not the correct version from workstations so this won't happen again.

SYMPTOM

I have installed the first workstation and can log into Dynamics fine. Why can't I just copy this directory to my other workstations and run Dynamics?

RESOLUTION

There are registry settings that Dynamics makes on each workstation during the install. Without these entries, Dynamics won't function. Once an install is done at each workstation, directories can be successfully copied to other workstations.