Unknown Error

[Hajee]

So I have this mod. It is finished, however I get this weird error message in the database and modding log.

[3841233.035] [Configuration] ERROR: no such table: Types
[3841233.035] Status: ModdingUpdateConfigurationDatabase - Loading Data/Gameplay.sql
[3841233.035] Warning: ModdingUpdateConfigurationDatabase - Error Loading SQL.

I find it strange that the table Types doesn't exist. I pulled up Sql lite, and sure enough types is a table. I played through the modded game and everything is there no crash, yet I still get this error.

It might be a no big deal, but OCD factor here.

Any Ideas?

 

[Gedemon]

It exists in the gameplay database, but not in the configuration database.

 

[Hajee]

It exists in the gameplay database, but not in the configuration database.

is there a way to fix that?

 

[Gedemon]

Difficult to say not knowing what you want to do with the Types table in the configuration database.

I'm not using modbuddy so I can't tell you how to change the database you want to update in it, but in the modinfo, this update the config database:

    <FrontEndActions>
        <UpdateDatabase id="GCO_SETTING">
            <File>Config/Config.xml</File>
        </UpdateDatabase>
    </FrontEndActions>

and this update the gameplay database:

    <InGameActions>   
        <UpdateDatabase id="GCO_DEFAULT_COMPONENT">
                <File>Data/GamePlay.xml</File>
        </UpdateDatabase>
    </InGameActions>

 

[Hajee]

I dont use mod buddy too.

So this issue is in the modinfo.

The is issue started after I was having saved game errors. I edited DLC units, so I put in <LoadOrder> which is the main change to the modinfo. I wonder if I did that wrong

 

[LeeS]

it has no purpose in the configuration database.

• don't pile Gameplay and Configuration code (sql or xmnl) into the same file
• UpdateDatabase actions in the FrontEnd (or Settings if creating the mod manually) should never contain files with code that is only valid in the In-Game (or Components if creating the mod manually) side of the database.
• UpdateDatabase actions in the In-Game (or Components if creating the mod manually) should never contain files with code that is only valid in the FrontEnd (or Settings if creating the mod manually) side of the database.

edit -- posts appeared while I was typing

if the error start after you edited the modinfo file to add a load order setting, then you most likely made a goof editing the modinfo file

 

[Hajee]

it has no purpose in the configuration database.

• don't pile Gameplay and Configuration code (sql or xmnl) into the same file
• UpdateDatabase actions in the FrontEnd (or Settings if creating the mod manually) should never contain files with code that is only valid in the In-Game (or Components if creating the mod manually) side of the database.
• UpdateDatabase actions in the In-Game (or Components if creating the mod manually) should never contain files with code that is only valid in the FrontEnd (or Settings if creating the mod manually) side of the database.

I dont have xml and sql in same file.
I am confused about two and three tho.

 

[Hajee]

This is how I have the settings and Componets set up

    <Settings>
        <Custom id="Tech_Civic_Tree_Revamp_Setting">
            <Items>
                <File>Data/Hajee_Config.xml</File>
                <File>Data/Gameplay.sql</File>
            </Items>
        </Custom>
    </Settings>
    
    <Components>
        <UpdateDatabase>
            <Properties>
                <RuleSet>Hajee_Rules</RuleSet>
                <LoadOrder>999</LoadOrder>
            </Properties>
            <Items>
                <File>Data/Gameplay.sql</File>
            </Items>       
        </UpdateDatabase>
       </Components>

 

[LeeS]

The game has two databases, each with entirely different definitions of what tables are valid and what columns within those tables are valid. Your sql (or xml) files must not mix between the two databases.

So stating an INSERT command for table "Types" within an SQL file that is being loaded into the game under a "FronEnd" action will only result in a fatal error such as you are getting for "no such table".

Taken from one of JFD's mods. The file RussiaElisabeth_Config.sql contains info written to tables that are only valid in the FrontEnd side of the database. The file RussiaElisabeth_GameDefines.sql contains info for tables that are only valid for the In-Game side of the database. Both are "UpdateDatabase" types of actions, however.

  <FrontEndActions>
    <UpdateDatabase id="JFDRussiaElisabeth_ConfigDatabase">
      <File>Core/RussiaElisabeth_Config.sql</File>
    </UpdateDatabase>
  </FrontEndActions>
  <InGameActions>
    <UpdateDatabase id="JFDRussiaElisabeth_Database">
      <File>Core/RussiaElisabeth_GameDefines.sql</File>
    </UpdateDatabase>
  </InGameActions>

 

[Hajee]

The game has two databases, each with entirely different definitions of what tables are valid and what columns within those tables are valid. Your sql (or xml) files must not mix between the two databases.

So stating an INSERT command for table "Types" within an SQL file that is being loaded into the game under a "FronEnd" action will only result in a fatal error such as you are getting for "no such table".

Taken from one of JFD's mods. The file RussiaElisabeth_Config.sql contains info written to tables that are only valid in the FrontEnd side of the database. The file RussiaElisabeth_GameDefines.sql contains info for tables that are only valid for the In-Game side of the database. Both are "UpdateDatabase" types of actions, however.

  <FrontEndActions>
    <UpdateDatabase id="JFDRussiaElisabeth_ConfigDatabase">
      <File>Core/RussiaElisabeth_Config.sql</File>
    </UpdateDatabase>
  </FrontEndActions>
  <InGameActions>
    <UpdateDatabase id="JFDRussiaElisabeth_Database">
      <File>Core/RussiaElisabeth_GameDefines.sql</File>
    </UpdateDatabase>
  </InGameActions>

I get that. I only have one file (sql)

 

[LeeS]

"Custom" as an action-type under the "Settings" header is equivalent to "UpdateDatabase" in the "FrontEndActions" header and the same rules apply to the contents of the files listed within these action-types.

 

[LeeS]

I get that. I only have one file (sql)

This is your problem. You cannot. You need one for the "Settings" stuff and an additional file for the "Components" stuff. This will be true even when using the modbuddy types of "FrontEndActions" and "InGame Actions"

This is what I meant by mixing your SQL or XML. Not that you are putting SQL and XMl into the same file, but that you are putting commands for the "Settings" database into the same file with commands for the "Components" database.

 

[Hajee]

This is your problem. You cannot. You need one for the "Settings" stuff and an additional file for the "Components" stuff. This will be true even when using the modbuddy types of "FrontEndActions" and "InGame Actions"

OKay I think I got you, so

    <Settings>
        <Custom id="Hajee_Rules_Setting">
            <Items>
                <File>Data/Hajee_Config.xml</File>
            </Items>
        </Custom>
    </Settings>
    
    <Components>
        <UpdateDatabase>
            <Properties>
                <RuleSet>Hajee_Rules</RuleSet>
                </Properties>
            <Items>
                <File>Data/Gameplay.sql</File>
                <LoadOrder>999</LoadOrder>
            </Items>       
        </UpdateDatabase>

I need to take the gameplay.sql out of settings then right

 

[LeeS]

Yes, except

    <Settings>
        <Custom id="Hajee_Rules_Setting">
            <Items>
                <File>Data/Hajee_Config.xml</File>
            </Items>
        </Custom>
    </Settings>
    
    <Components>
        <UpdateDatabase id="Something">
            <Properties>
                <RuleSet>Hajee_Rules</RuleSet>
                <LoadOrder>999</LoadOrder>
            </Properties>
            <Items>
                <File>Data/Gameplay.sql</File>
            </Items>       
        </UpdateDatabase>
    </Components>

 

[Hajee]

okay perfect, ya I was playing with the load order as unsure. I move that back.


Right on thank you both very much