Why do I have multiple (unassociated) temporal history tables?












4















I have been setting up a proof of concept system which has a SQL Server 2017 back end.

The system uses temporal tables to record asset configurations and track changes over time.

I have a Data table which is linked to the history table, let's call it dbo.MSSQL_TemporaryHistoryFor_12345678900.



So far so good. I have two issues:



Today I turned off versioning on the table so I could add a computed column. This was done and turned back on again without errors.



Now I find that I cannot query any historic data from before the change. New data is being added to the history, but there is nothing beforehand.



Looking inside SSMS, I can now see there are multiple history tables, all with the same name but with a hex suffix, e.g. dbo.MSSQL_TemporaryHistoryFor_12345678900_A0B1C2D3. They are not linked beneath the main data table. They are just floating around on their own inside the database. When I queried sys.tables, these are not shown as history tables and are not linked to the main data table.



These tables do contain the historical data which is missing.



The questions I have are therefore:




  • What do these additional tables represent?

  • How were they created?

  • Is there any way to somehow relink these into the main history chain so I can get my historical reporting back?


It's very frustrating so any help you can provide would be gratefully received. Thanks.










share|improve this question









New contributor




MrB is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
















  • 1





    It might be helpful if you provide the commands you ran before you got into this state.

    – LowlyDBA
    9 hours ago
















4















I have been setting up a proof of concept system which has a SQL Server 2017 back end.

The system uses temporal tables to record asset configurations and track changes over time.

I have a Data table which is linked to the history table, let's call it dbo.MSSQL_TemporaryHistoryFor_12345678900.



So far so good. I have two issues:



Today I turned off versioning on the table so I could add a computed column. This was done and turned back on again without errors.



Now I find that I cannot query any historic data from before the change. New data is being added to the history, but there is nothing beforehand.



Looking inside SSMS, I can now see there are multiple history tables, all with the same name but with a hex suffix, e.g. dbo.MSSQL_TemporaryHistoryFor_12345678900_A0B1C2D3. They are not linked beneath the main data table. They are just floating around on their own inside the database. When I queried sys.tables, these are not shown as history tables and are not linked to the main data table.



These tables do contain the historical data which is missing.



The questions I have are therefore:




  • What do these additional tables represent?

  • How were they created?

  • Is there any way to somehow relink these into the main history chain so I can get my historical reporting back?


It's very frustrating so any help you can provide would be gratefully received. Thanks.










share|improve this question









New contributor




MrB is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
















  • 1





    It might be helpful if you provide the commands you ran before you got into this state.

    – LowlyDBA
    9 hours ago














4












4








4








I have been setting up a proof of concept system which has a SQL Server 2017 back end.

The system uses temporal tables to record asset configurations and track changes over time.

I have a Data table which is linked to the history table, let's call it dbo.MSSQL_TemporaryHistoryFor_12345678900.



So far so good. I have two issues:



Today I turned off versioning on the table so I could add a computed column. This was done and turned back on again without errors.



Now I find that I cannot query any historic data from before the change. New data is being added to the history, but there is nothing beforehand.



Looking inside SSMS, I can now see there are multiple history tables, all with the same name but with a hex suffix, e.g. dbo.MSSQL_TemporaryHistoryFor_12345678900_A0B1C2D3. They are not linked beneath the main data table. They are just floating around on their own inside the database. When I queried sys.tables, these are not shown as history tables and are not linked to the main data table.



These tables do contain the historical data which is missing.



The questions I have are therefore:




  • What do these additional tables represent?

  • How were they created?

  • Is there any way to somehow relink these into the main history chain so I can get my historical reporting back?


It's very frustrating so any help you can provide would be gratefully received. Thanks.










share|improve this question









New contributor




MrB is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.












I have been setting up a proof of concept system which has a SQL Server 2017 back end.

The system uses temporal tables to record asset configurations and track changes over time.

I have a Data table which is linked to the history table, let's call it dbo.MSSQL_TemporaryHistoryFor_12345678900.



So far so good. I have two issues:



Today I turned off versioning on the table so I could add a computed column. This was done and turned back on again without errors.



Now I find that I cannot query any historic data from before the change. New data is being added to the history, but there is nothing beforehand.



Looking inside SSMS, I can now see there are multiple history tables, all with the same name but with a hex suffix, e.g. dbo.MSSQL_TemporaryHistoryFor_12345678900_A0B1C2D3. They are not linked beneath the main data table. They are just floating around on their own inside the database. When I queried sys.tables, these are not shown as history tables and are not linked to the main data table.



These tables do contain the historical data which is missing.



The questions I have are therefore:




  • What do these additional tables represent?

  • How were they created?

  • Is there any way to somehow relink these into the main history chain so I can get my historical reporting back?


It's very frustrating so any help you can provide would be gratefully received. Thanks.







sql-server sql-server-2017 temporal-tables






share|improve this question









New contributor




MrB is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.











share|improve this question









New contributor




MrB is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.









share|improve this question




share|improve this question








edited 8 hours ago









jadarnel27

6,01811938




6,01811938






New contributor




MrB is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.









asked 10 hours ago









MrBMrB

232




232




New contributor




MrB is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.





New contributor





MrB is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.






MrB is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.








  • 1





    It might be helpful if you provide the commands you ran before you got into this state.

    – LowlyDBA
    9 hours ago














  • 1





    It might be helpful if you provide the commands you ran before you got into this state.

    – LowlyDBA
    9 hours ago








1




1





It might be helpful if you provide the commands you ran before you got into this state.

– LowlyDBA
9 hours ago





It might be helpful if you provide the commands you ran before you got into this state.

– LowlyDBA
9 hours ago










1 Answer
1






active

oldest

votes


















3














The docs should really be more clear on this, but you need to provide the name of the history table in order to maintain data continuity when turning system versioning off and on. This behavior is mentioned in the documentation for ALTER TABLE:




If you don't use the HISTORY_TABLE argument, the system generates a new history table matching the schema of the current table, creates a link between the two tables, and enables the system to record the history of each record in the current table in the history table.




Here's a demo. I'll create the example table from the documentation:



CREATE TABLE dbo.Employee   
(
[EmployeeID] int NOT NULL PRIMARY KEY CLUSTERED
, [Name] nvarchar(100) NOT NULL
, [Position] varchar(100) NOT NULL
, [Department] varchar(100) NOT NULL
, [Address] nvarchar(1024) NOT NULL
, [AnnualSalary] decimal (10,2) NOT NULL
, [ValidFrom] datetime2 (2) GENERATED ALWAYS AS ROW START
, [ValidTo] datetime2 (2) GENERATED ALWAYS AS ROW END
, PERIOD FOR SYSTEM_TIME (ValidFrom, ValidTo)
)
WITH (SYSTEM_VERSIONING = ON);


This results in a history table named MSSQL_TemporalHistoryFor_1253579504. Now I'll disabled and enable system versioning:



ALTER TABLE dbo.Employee SET (SYSTEM_VERSIONING = OFF);
ALTER TABLE dbo.Employee SET (SYSTEM_VERSIONING = ON);


And I'm in your exact situation:



enter image description here





Now I'll clean everything up:



ALTER TABLE dbo.Employee SET (SYSTEM_VERSIONING = OFF);
DROP TABLE dbo.Employee;
DROP TABLE dbo.MSSQL_TemporalHistoryFor_1253579504;
DROP TABLE dbo.MSSQL_TemporalHistoryFor_1253579504_D0055BB4;


Then create the table with a specific history table name:



 CREATE TABLE dbo.Employee   
(
[EmployeeID] int NOT NULL PRIMARY KEY CLUSTERED
, [Name] nvarchar(100) NOT NULL
, [Position] varchar(100) NOT NULL
, [Department] varchar(100) NOT NULL
, [Address] nvarchar(1024) NOT NULL
, [AnnualSalary] decimal (10,2) NOT NULL
, [ValidFrom] datetime2 (2) GENERATED ALWAYS AS ROW START
, [ValidTo] datetime2 (2) GENERATED ALWAYS AS ROW END
, PERIOD FOR SYSTEM_TIME (ValidFrom, ValidTo)
)
WITH (SYSTEM_VERSIONING = ON (HISTORY_TABLE = dbo.EmployeeHistory));


The turn system versioning off and on, but continue specifying the history table name:



ALTER TABLE dbo.Employee SET (SYSTEM_VERSIONING = OFF);
ALTER TABLE dbo.Employee SET (SYSTEM_VERSIONING = ON (HISTORY_TABLE = dbo.EmployeeHistory));


Note: in your specific situation, you should be able to use this syntax to "reattach" one lost history table to your base table



No extra tables:



enter image description here



The takeaway



Always specify a history table name explicitly when creating temporal tables or enabling system versioning.



I've submitted a PR to MS Docs to add a reminder about this behavior on the Stopping System-Versioning on a System-Versioned Temporal Table page.






share|improve this answer

























    Your Answer








    StackExchange.ready(function() {
    var channelOptions = {
    tags: "".split(" "),
    id: "182"
    };
    initTagRenderer("".split(" "), "".split(" "), channelOptions);

    StackExchange.using("externalEditor", function() {
    // Have to fire editor after snippets, if snippets enabled
    if (StackExchange.settings.snippets.snippetsEnabled) {
    StackExchange.using("snippets", function() {
    createEditor();
    });
    }
    else {
    createEditor();
    }
    });

    function createEditor() {
    StackExchange.prepareEditor({
    heartbeatType: 'answer',
    autoActivateHeartbeat: false,
    convertImagesToLinks: false,
    noModals: true,
    showLowRepImageUploadWarning: true,
    reputationToPostImages: null,
    bindNavPrevention: true,
    postfix: "",
    imageUploader: {
    brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
    contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
    allowUrls: true
    },
    onDemand: true,
    discardSelector: ".discard-answer"
    ,immediatelyShowMarkdownHelp:true
    });


    }
    });






    MrB is a new contributor. Be nice, and check out our Code of Conduct.










    draft saved

    draft discarded


















    StackExchange.ready(
    function () {
    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fdba.stackexchange.com%2fquestions%2f231047%2fwhy-do-i-have-multiple-unassociated-temporal-history-tables%23new-answer', 'question_page');
    }
    );

    Post as a guest















    Required, but never shown

























    1 Answer
    1






    active

    oldest

    votes








    1 Answer
    1






    active

    oldest

    votes









    active

    oldest

    votes






    active

    oldest

    votes









    3














    The docs should really be more clear on this, but you need to provide the name of the history table in order to maintain data continuity when turning system versioning off and on. This behavior is mentioned in the documentation for ALTER TABLE:




    If you don't use the HISTORY_TABLE argument, the system generates a new history table matching the schema of the current table, creates a link between the two tables, and enables the system to record the history of each record in the current table in the history table.




    Here's a demo. I'll create the example table from the documentation:



    CREATE TABLE dbo.Employee   
    (
    [EmployeeID] int NOT NULL PRIMARY KEY CLUSTERED
    , [Name] nvarchar(100) NOT NULL
    , [Position] varchar(100) NOT NULL
    , [Department] varchar(100) NOT NULL
    , [Address] nvarchar(1024) NOT NULL
    , [AnnualSalary] decimal (10,2) NOT NULL
    , [ValidFrom] datetime2 (2) GENERATED ALWAYS AS ROW START
    , [ValidTo] datetime2 (2) GENERATED ALWAYS AS ROW END
    , PERIOD FOR SYSTEM_TIME (ValidFrom, ValidTo)
    )
    WITH (SYSTEM_VERSIONING = ON);


    This results in a history table named MSSQL_TemporalHistoryFor_1253579504. Now I'll disabled and enable system versioning:



    ALTER TABLE dbo.Employee SET (SYSTEM_VERSIONING = OFF);
    ALTER TABLE dbo.Employee SET (SYSTEM_VERSIONING = ON);


    And I'm in your exact situation:



    enter image description here





    Now I'll clean everything up:



    ALTER TABLE dbo.Employee SET (SYSTEM_VERSIONING = OFF);
    DROP TABLE dbo.Employee;
    DROP TABLE dbo.MSSQL_TemporalHistoryFor_1253579504;
    DROP TABLE dbo.MSSQL_TemporalHistoryFor_1253579504_D0055BB4;


    Then create the table with a specific history table name:



     CREATE TABLE dbo.Employee   
    (
    [EmployeeID] int NOT NULL PRIMARY KEY CLUSTERED
    , [Name] nvarchar(100) NOT NULL
    , [Position] varchar(100) NOT NULL
    , [Department] varchar(100) NOT NULL
    , [Address] nvarchar(1024) NOT NULL
    , [AnnualSalary] decimal (10,2) NOT NULL
    , [ValidFrom] datetime2 (2) GENERATED ALWAYS AS ROW START
    , [ValidTo] datetime2 (2) GENERATED ALWAYS AS ROW END
    , PERIOD FOR SYSTEM_TIME (ValidFrom, ValidTo)
    )
    WITH (SYSTEM_VERSIONING = ON (HISTORY_TABLE = dbo.EmployeeHistory));


    The turn system versioning off and on, but continue specifying the history table name:



    ALTER TABLE dbo.Employee SET (SYSTEM_VERSIONING = OFF);
    ALTER TABLE dbo.Employee SET (SYSTEM_VERSIONING = ON (HISTORY_TABLE = dbo.EmployeeHistory));


    Note: in your specific situation, you should be able to use this syntax to "reattach" one lost history table to your base table



    No extra tables:



    enter image description here



    The takeaway



    Always specify a history table name explicitly when creating temporal tables or enabling system versioning.



    I've submitted a PR to MS Docs to add a reminder about this behavior on the Stopping System-Versioning on a System-Versioned Temporal Table page.






    share|improve this answer






























      3














      The docs should really be more clear on this, but you need to provide the name of the history table in order to maintain data continuity when turning system versioning off and on. This behavior is mentioned in the documentation for ALTER TABLE:




      If you don't use the HISTORY_TABLE argument, the system generates a new history table matching the schema of the current table, creates a link between the two tables, and enables the system to record the history of each record in the current table in the history table.




      Here's a demo. I'll create the example table from the documentation:



      CREATE TABLE dbo.Employee   
      (
      [EmployeeID] int NOT NULL PRIMARY KEY CLUSTERED
      , [Name] nvarchar(100) NOT NULL
      , [Position] varchar(100) NOT NULL
      , [Department] varchar(100) NOT NULL
      , [Address] nvarchar(1024) NOT NULL
      , [AnnualSalary] decimal (10,2) NOT NULL
      , [ValidFrom] datetime2 (2) GENERATED ALWAYS AS ROW START
      , [ValidTo] datetime2 (2) GENERATED ALWAYS AS ROW END
      , PERIOD FOR SYSTEM_TIME (ValidFrom, ValidTo)
      )
      WITH (SYSTEM_VERSIONING = ON);


      This results in a history table named MSSQL_TemporalHistoryFor_1253579504. Now I'll disabled and enable system versioning:



      ALTER TABLE dbo.Employee SET (SYSTEM_VERSIONING = OFF);
      ALTER TABLE dbo.Employee SET (SYSTEM_VERSIONING = ON);


      And I'm in your exact situation:



      enter image description here





      Now I'll clean everything up:



      ALTER TABLE dbo.Employee SET (SYSTEM_VERSIONING = OFF);
      DROP TABLE dbo.Employee;
      DROP TABLE dbo.MSSQL_TemporalHistoryFor_1253579504;
      DROP TABLE dbo.MSSQL_TemporalHistoryFor_1253579504_D0055BB4;


      Then create the table with a specific history table name:



       CREATE TABLE dbo.Employee   
      (
      [EmployeeID] int NOT NULL PRIMARY KEY CLUSTERED
      , [Name] nvarchar(100) NOT NULL
      , [Position] varchar(100) NOT NULL
      , [Department] varchar(100) NOT NULL
      , [Address] nvarchar(1024) NOT NULL
      , [AnnualSalary] decimal (10,2) NOT NULL
      , [ValidFrom] datetime2 (2) GENERATED ALWAYS AS ROW START
      , [ValidTo] datetime2 (2) GENERATED ALWAYS AS ROW END
      , PERIOD FOR SYSTEM_TIME (ValidFrom, ValidTo)
      )
      WITH (SYSTEM_VERSIONING = ON (HISTORY_TABLE = dbo.EmployeeHistory));


      The turn system versioning off and on, but continue specifying the history table name:



      ALTER TABLE dbo.Employee SET (SYSTEM_VERSIONING = OFF);
      ALTER TABLE dbo.Employee SET (SYSTEM_VERSIONING = ON (HISTORY_TABLE = dbo.EmployeeHistory));


      Note: in your specific situation, you should be able to use this syntax to "reattach" one lost history table to your base table



      No extra tables:



      enter image description here



      The takeaway



      Always specify a history table name explicitly when creating temporal tables or enabling system versioning.



      I've submitted a PR to MS Docs to add a reminder about this behavior on the Stopping System-Versioning on a System-Versioned Temporal Table page.






      share|improve this answer




























        3












        3








        3







        The docs should really be more clear on this, but you need to provide the name of the history table in order to maintain data continuity when turning system versioning off and on. This behavior is mentioned in the documentation for ALTER TABLE:




        If you don't use the HISTORY_TABLE argument, the system generates a new history table matching the schema of the current table, creates a link between the two tables, and enables the system to record the history of each record in the current table in the history table.




        Here's a demo. I'll create the example table from the documentation:



        CREATE TABLE dbo.Employee   
        (
        [EmployeeID] int NOT NULL PRIMARY KEY CLUSTERED
        , [Name] nvarchar(100) NOT NULL
        , [Position] varchar(100) NOT NULL
        , [Department] varchar(100) NOT NULL
        , [Address] nvarchar(1024) NOT NULL
        , [AnnualSalary] decimal (10,2) NOT NULL
        , [ValidFrom] datetime2 (2) GENERATED ALWAYS AS ROW START
        , [ValidTo] datetime2 (2) GENERATED ALWAYS AS ROW END
        , PERIOD FOR SYSTEM_TIME (ValidFrom, ValidTo)
        )
        WITH (SYSTEM_VERSIONING = ON);


        This results in a history table named MSSQL_TemporalHistoryFor_1253579504. Now I'll disabled and enable system versioning:



        ALTER TABLE dbo.Employee SET (SYSTEM_VERSIONING = OFF);
        ALTER TABLE dbo.Employee SET (SYSTEM_VERSIONING = ON);


        And I'm in your exact situation:



        enter image description here





        Now I'll clean everything up:



        ALTER TABLE dbo.Employee SET (SYSTEM_VERSIONING = OFF);
        DROP TABLE dbo.Employee;
        DROP TABLE dbo.MSSQL_TemporalHistoryFor_1253579504;
        DROP TABLE dbo.MSSQL_TemporalHistoryFor_1253579504_D0055BB4;


        Then create the table with a specific history table name:



         CREATE TABLE dbo.Employee   
        (
        [EmployeeID] int NOT NULL PRIMARY KEY CLUSTERED
        , [Name] nvarchar(100) NOT NULL
        , [Position] varchar(100) NOT NULL
        , [Department] varchar(100) NOT NULL
        , [Address] nvarchar(1024) NOT NULL
        , [AnnualSalary] decimal (10,2) NOT NULL
        , [ValidFrom] datetime2 (2) GENERATED ALWAYS AS ROW START
        , [ValidTo] datetime2 (2) GENERATED ALWAYS AS ROW END
        , PERIOD FOR SYSTEM_TIME (ValidFrom, ValidTo)
        )
        WITH (SYSTEM_VERSIONING = ON (HISTORY_TABLE = dbo.EmployeeHistory));


        The turn system versioning off and on, but continue specifying the history table name:



        ALTER TABLE dbo.Employee SET (SYSTEM_VERSIONING = OFF);
        ALTER TABLE dbo.Employee SET (SYSTEM_VERSIONING = ON (HISTORY_TABLE = dbo.EmployeeHistory));


        Note: in your specific situation, you should be able to use this syntax to "reattach" one lost history table to your base table



        No extra tables:



        enter image description here



        The takeaway



        Always specify a history table name explicitly when creating temporal tables or enabling system versioning.



        I've submitted a PR to MS Docs to add a reminder about this behavior on the Stopping System-Versioning on a System-Versioned Temporal Table page.






        share|improve this answer















        The docs should really be more clear on this, but you need to provide the name of the history table in order to maintain data continuity when turning system versioning off and on. This behavior is mentioned in the documentation for ALTER TABLE:




        If you don't use the HISTORY_TABLE argument, the system generates a new history table matching the schema of the current table, creates a link between the two tables, and enables the system to record the history of each record in the current table in the history table.




        Here's a demo. I'll create the example table from the documentation:



        CREATE TABLE dbo.Employee   
        (
        [EmployeeID] int NOT NULL PRIMARY KEY CLUSTERED
        , [Name] nvarchar(100) NOT NULL
        , [Position] varchar(100) NOT NULL
        , [Department] varchar(100) NOT NULL
        , [Address] nvarchar(1024) NOT NULL
        , [AnnualSalary] decimal (10,2) NOT NULL
        , [ValidFrom] datetime2 (2) GENERATED ALWAYS AS ROW START
        , [ValidTo] datetime2 (2) GENERATED ALWAYS AS ROW END
        , PERIOD FOR SYSTEM_TIME (ValidFrom, ValidTo)
        )
        WITH (SYSTEM_VERSIONING = ON);


        This results in a history table named MSSQL_TemporalHistoryFor_1253579504. Now I'll disabled and enable system versioning:



        ALTER TABLE dbo.Employee SET (SYSTEM_VERSIONING = OFF);
        ALTER TABLE dbo.Employee SET (SYSTEM_VERSIONING = ON);


        And I'm in your exact situation:



        enter image description here





        Now I'll clean everything up:



        ALTER TABLE dbo.Employee SET (SYSTEM_VERSIONING = OFF);
        DROP TABLE dbo.Employee;
        DROP TABLE dbo.MSSQL_TemporalHistoryFor_1253579504;
        DROP TABLE dbo.MSSQL_TemporalHistoryFor_1253579504_D0055BB4;


        Then create the table with a specific history table name:



         CREATE TABLE dbo.Employee   
        (
        [EmployeeID] int NOT NULL PRIMARY KEY CLUSTERED
        , [Name] nvarchar(100) NOT NULL
        , [Position] varchar(100) NOT NULL
        , [Department] varchar(100) NOT NULL
        , [Address] nvarchar(1024) NOT NULL
        , [AnnualSalary] decimal (10,2) NOT NULL
        , [ValidFrom] datetime2 (2) GENERATED ALWAYS AS ROW START
        , [ValidTo] datetime2 (2) GENERATED ALWAYS AS ROW END
        , PERIOD FOR SYSTEM_TIME (ValidFrom, ValidTo)
        )
        WITH (SYSTEM_VERSIONING = ON (HISTORY_TABLE = dbo.EmployeeHistory));


        The turn system versioning off and on, but continue specifying the history table name:



        ALTER TABLE dbo.Employee SET (SYSTEM_VERSIONING = OFF);
        ALTER TABLE dbo.Employee SET (SYSTEM_VERSIONING = ON (HISTORY_TABLE = dbo.EmployeeHistory));


        Note: in your specific situation, you should be able to use this syntax to "reattach" one lost history table to your base table



        No extra tables:



        enter image description here



        The takeaway



        Always specify a history table name explicitly when creating temporal tables or enabling system versioning.



        I've submitted a PR to MS Docs to add a reminder about this behavior on the Stopping System-Versioning on a System-Versioned Temporal Table page.







        share|improve this answer














        share|improve this answer



        share|improve this answer








        edited 8 hours ago

























        answered 9 hours ago









        jadarnel27jadarnel27

        6,01811938




        6,01811938






















            MrB is a new contributor. Be nice, and check out our Code of Conduct.










            draft saved

            draft discarded


















            MrB is a new contributor. Be nice, and check out our Code of Conduct.













            MrB is a new contributor. Be nice, and check out our Code of Conduct.












            MrB is a new contributor. Be nice, and check out our Code of Conduct.
















            Thanks for contributing an answer to Database Administrators Stack Exchange!


            • Please be sure to answer the question. Provide details and share your research!

            But avoid



            • Asking for help, clarification, or responding to other answers.

            • Making statements based on opinion; back them up with references or personal experience.


            To learn more, see our tips on writing great answers.




            draft saved


            draft discarded














            StackExchange.ready(
            function () {
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fdba.stackexchange.com%2fquestions%2f231047%2fwhy-do-i-have-multiple-unassociated-temporal-history-tables%23new-answer', 'question_page');
            }
            );

            Post as a guest















            Required, but never shown





















































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown

































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown