We’ve developed some resources to help you work effectively from home during COVID-19 Click to learn more

G9 error when connecting to existing database

Hello!

I've been trying to upgrade an 8.2 database to the new G9. However I'm encountering this error:

The ODBC source can connect just fine to the database from the server I'm doing this from. The DB user works as it should as well as the system user specified.

Since I know the settings are correct I tried running SQL profiler, and when hitting the "Check the database" button this occurs:

So it seems like it's connecting. Logfile from the serversetup.exe gives this error:

----

Inner Element:
Message: Could not connect to database. An event has been logged
Type: SuperOffice.Exceptions.SoDbAccessException
Details:
at SuperOffice.Data.SoConnection.Open()
at SuperOffice.Data.SoDatabase.Init()

Inner Element:
Message: A network-related or instance-specific error occurred while establishing a connection to SQL Server. The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections. (provider: Named Pipes Provider, error: 40 - Could not open a connection to SQL Server)

----

I'm experiencing this error at a customer as well as on my local machine in my test environments. With different serials and DB's. 

Anyone encountered this?

 

 

RE: G9 error when connecting to existing database

Hello,

In your screenshot I see you filled in CRM as prefix/schema, but in the query log/trace query's are done with CRM7 as prefix.

Do you have a reference to crm7 as schema/prefix somewhere in the SuperOffice.config or SuperOffice.ini?

Maybe an schema/prefix configured on the crm7 sql user?

 

Av: David Hollegien 2. sep 2020

RE: G9 error when connecting to existing database

Hi,

Yes. Sorry. Screenshot is a bit off. I've tried several instances. I went from a crm7 user in all configs and sql as well as table prefix, and tried creating a crm user instead to see if there was any difference. So the screenshot is just a bit off after mixing and matching a bit into the troubleshooting process.

This screenshot is better.

Av: Marius Gabrielsen 2. sep 2020

RE: G9 error when connecting to existing database

Hello Marius,

If you go to your temp folder (%localappdata%\temp), do you see any errors in the so_log.txt or so_log.Database.log?

Av: David Hollegien 2. sep 2020

RE: G9 error when connecting to existing database

Hi David,

From the so_log.txt in %temp% I get this when running the serversetup at the step mentioned:

200902 14:18:29 CRM        Login (ds:ODBC:85 uid:CRM pre:CRM )
200902 14:18:29                  [ServerSetup.exe] DBMS name: Microsoft SQL Server, version: 12.00.2000, recognised as MS SQL Server 12.0 (2014). Src: SODBCConnection::SetDBMSType at C:\Agent1\_work\42\s\Clients\SM.win\Source\DBDLL\Dodcon.cpp v line 443 
System.Exception: Field valueType [Enum->CriterionValueType] in table SearchCriterionValue had type 11 when this code was generated, but is Enum in the database. This is not compatible and the client cannot run.
		   at SDictionaryFromModel._LoadFromModel(SvStr* i_CDB, SvStr* i_SchemaName, SvStr* i_ConnectionString, SvStr* i_DynamicDriverAssembly, SvStr* i_DynamicDriverType, SvStr* i_DatabaseMajor, SvStr* i_DatabaseMinor, SvStr* i_TablePrefix, EDBMSType i_DbType, Boolean i_ReadAllFieldsWithoutFiltering)
200902 14:18:30            3.1001[ServerSetup.exe] Error calling: SDictionaryFromModel::_LoadFromModel
Field valueType [Enum->CriterionValueType] in table SearchCriterionValue had type 11 when this code was generated, but is Enum in the database. This is not compatible and the client cannot run. Src: DbOpenRawDatabase at C:\Agent1\_work\42\s\Clients\SM.win\Source\DBDLL\Dapi.cpp v line 277 
200902 14:18:30            3.1001[ServerSetup.exe] Error calling: SDictionaryFromModel::_LoadFromModel
Field valueType [Enum->CriterionValueType] in table SearchCriterionValue had type 11 when this code was generated, but is Enum in the database. This is not compatible and the client cannot run. 

No so_log.database.log is created. Probably since I'm stuck before it's generated.

Compairing my table to Frode and his database this is mine:

and this is Frode's: