Thank you for the response. This is being done for development of an external application. The setup is a new server VM, and a clean install of Sage 6.0A (500). Company and system database backed up at the same time and restored to a different SQL server with the same database names. Sage Database setup uses the same ID as the original server.

1. There is a single record with PGMID = AS, PGMVER = 60A and DATALEVEL = 0.

2. PU1 has been installed and verified in the System Information screen.

3. The company database is linked to the system database. Both of which were restored from SQL backups.

4. Database IDs are the same on both systems.

Hi Rob, if this is a system being setup in parallel as a development environment, definitely take a copy of the programs from the original server as you may not know what add-on modules you're missing - I would click Help -> System Information in the original system and take a screenshot of all the red check marks to ensure you have all required modules.  You can also confirm you're definitely at the same Product Update level this way too.  Definitely dump and load the databases as there must be an inconsistency.  You're receiving that error message either because the modules genuinely are a Product Update or main version behind the production system OR the Company/System database relationships are wrong.  If you open Database Setup in the production system and click Profile -> Print you can run off a report with the correct relationships.  Finally it could still be the ID's are wrong do definitely dump and load all databases.  Also try selecting * from CSAPP on all databases to see if you can glean some more information on the module versions.  Finally, I know this is obvious, but this is a very old and unsupported version of Sage 300 to be investing development work - the client is 14 versions behind the current release!

Based on the printout, the database relationships are correct.  When you say "take a copy of the programs", are you saying just zip up the sage directory and copied it over what I have already installed?

Hi Rob, great to know the relationships are solid.  You got it - I would rename your new Sage 300 folder you just installed, then zip up the old one and extract it in place.  Make sure to rename it to be the same as what you just installed.  You're essentially doing a bait and switch.  Now to save yourself some time, ignore any Backup or Data Dump folders when you do the ZIP, and also check underneath the COMPANY and DATA folders to ensure there isn't any large folders or files under there - you don't need them.  If COMPANY and DATA are large, i.e. over 50MB, try leaving them out, you shouldn't need them.  Now when you put this copy of the clients programs in place off their main production system, you will inherit their database settings, user passwords, everything.  So the ADMIN password will now be the production one and you will need to open Database Setup and fix up the SQL server details.  If you don't know the ADMIN password in production and can't acquire it, you can copy the contents of SITE from your newly installed Sage 300 folder to the Production one, but try to keep Production as in tact as possible for best results.  Once you have identical Production applications and the database setup fixed, you should be good to go as you've just cloned the Production site.  Sage 300 2010 (6.0A) is like a car from the 80's or earlier - its easy to work on and swapping parts is a breeze.  You don't need to worry about services, IIS components, etc.  Good luck!

I did all of this and still get the same message.

Is there a way to determine the version if the 2 databases?

Here is what I found in CSAPP in the company database. Seems AS should be 60A.

Hi Rob Trainer all good, this means the SQL backup is likely bad too - perhaps because not everything in memory was committed and written to disk during the .BAK backups.  I wasn't correct when I said the sites were identical because the databases were still an outlier.  All of these are educated guesses of course but doing my best.  Use the Database Dump tool to take your Company and System databases from production.  Zip them up (they will compress right down), extract and then Data Load them in at the other end.  It wouldn't be a first time databases restored from SQL bak's have gone poorly with this type of error.  This will also erase any SQL compatibility, collation and other myriad potential issues with such an old version.  Also, remove any problems with SQL Compatibility mode by deleting the databases on the new SQL server and re-creating them before loading.  So to recap:

1. Use the Database Dump tool on the production site to dump proper Sage 300 backups to a folder.  The structure will be in the folder you select you will get a single dictionary file (*.DCT) for each company database, and a subfolder will have been created for each database.  In each subfolder you will have a series of .REC files - one for each table.
2. ZIP up the database dumps at the top level of the backup with the .DCT's at the top of the ZIP and the subfolders underneath.
3. Copy and extract onto the new server into a folder.
4. Delete the databases in the management studio you created earlier.
5. Re-create the databases so you have fresh blank shells at the native SQL compatibility level, default collation (or use LATIN1_GENERAL_CI_AS if you have some other non-standard default).  Best to create these databases with SA or the same account you're using to connect the databases in Database Setup.
6. Open Database Setup, double-click on each database and click OK to ensure they're still connected properly.
7. Use the Database Load tool to point to the *.DCT files you backed up earlier with the subfolders sitting underneath.
8. Select the first backup, click Next, select the matching database, Click Next -> repeat until all matched and click Finish.
9. Once loaded you will have the Programs the same and identical data.

Good Luck.  If that still doesn't work, let us know and will keep trying for you.  If you get fed up, highly recommend a Sage 300 Business Partner to log in so they can actually see what's going on to help

Just trying to avoid the length dump/load.

Dump/load won't change anything

Well Jay Converse Acumen is gospel and if he says it won't change anything it won't.  If you have identical programs and identical data, its difficult to understand how the issue can occur.  Try to focus on what's different.  At the end of the day, its a full ERP not a small accounting program like MYOB, Xero, etc, so its not unusual, especially with such an old version, that you will need to invest some decent time and resources to get this up and running.  All the best, I'm afraid I'm out of ideas for you and I worked extensively supporting version 6.0 back when it was released.

 Rob Trainer  - AS68A - that's Sage 300 2021 NOT version 6.0 (2010).  Version 2021 of Sage 300 has attempted to open that data set.  You won't be able to go backwards now.  If production is version 2021, move forward with that.  If its not, version 2021 was installed accidentally somewhere and connected to those databases, you will have to find clean data and go back to all 60A records.  You might be able to change some records back and restart with a fresh, blank system database but if some of the data is already messed up, you'll be in a world of hurt without clean data.  All the best

But how is this working in production?

I get that if there was an upgrade done that there would potentially be assemblies that are 68A instead of 60A. But that said, I copied the entire directory and replaced it on the development VM. So those files should be in p[ace on that new VM.

Great question! It means the data set was attempted to be opened in Sage 300 2021 and the Data Activation of all separate modules not continued through to version 2021.  Best idea is to locate a production user actually actively working in the system, then go to Help -> System Information (if version 2010) or Help -> Sage Support -> Support Utilities -> System Information.  Then post a screenshot here of what's going on from a Production User:

Hi Rob Trainer that looks like a clean site!  Weird the version 6.7A (Sage 300 2020) SDK is installed - hope no one tries to do anything with it in prod, but anyways, irrelevant for the task at hand.  OK so I would try updating any 68A values to 60A values in CSAPP in your DEV environment (check company and system databases), as according to those screenshots it should be impossible for a 68A reference to be anywhere in that data set, and that reference is causing System Manager (Module = AS) to think its reading data from a newer version of Sage 300, resulting in your error.  Ideally you want to copy clean all 60A data from Prod again, but if you want to try and save time, try fixing those 68A references to 60A in your DEV data and see how you go.  Fingers crossed.

I tried updating the 2 places in CSAPP in the company database to 60A and Sage died. Should there be more than 1 record in the system copy of CSAPP? I only have 1.

Hi Rob Trainer CSAPP in the System Database normally only has one row so that's normal.  Unfortunately, with Common Services (CS) activated to version 68A the data is likely too far along to go back to 60A.  By "died" was it a crash without error?  If there is a clear error there may be something that can be done though at this stage you're likely stuck without loading fresh data.  Not sure what you want to do from here.  If it were me I would take the hit and dump the data out of Prod using the Sage 300 Database Dump tool, and bring it into dev using the Database Load tool for best possible outcome, but I understand your time constrained.  

Thought about this last night and realized that the copy of the company database on the development VM had corrupted by opening it with Sage 2021. This morning, I restored the company database and can now login to 6.0. That said, I still have a problem with data activation.

When I open the Data Activation screen, there aren't any applications to active listed.

That simply means there's nothing new to activate.

So how to get rid of the message. Right now, the only thing that I have access to is GL.

Install the RA60 folder

It is already there.

Probably not the right RA service pack.  Help/System Info may give clues.

Looks like that is the problem. I installed PU2.7 and can now access everything. Need to find PU2.8 though just to be consistent.

Jay Converse Acumen Accsys Consulting AU Thank you for all of you help.

No worries Rob, glad we could help.  If Prod is running RA PU 2.8 then copying the program folders from Prod over the top of DEV will resolve this without needing an installer.  Or just grab the RA folder at least, but if you want an exact copy of Prod's environment to avoid more problems, just copy over the top.  Don't forget to run REGACC.EXE from an elevated command prompt to register all these changed DLLs and OCXs in the registry.

No worries Rob, glad we could help.  If Prod is running RA PU 2.8 then copying the program folders from Prod over the top of DEV will resolve this without needing an installer.  Or just grab the RA folder at least, but if you want an exact copy of Prod's environment to avoid more problems, just copy over the top.  Don't forget to run REGACC.EXE from an elevated command prompt to register all these changed DLLs and OCXs in the registry.