# SQL migration using SSMA, tables need database reference

**URL:** <https://forum.inductiveautomation.com/t/sql-migration-using-ssma-tables-need-database-reference/17851>\
**Category:** Ignition\
**Tags:** ignition79, database\
**Created:** [April 27, 2018, 4:43pm UTC](https://forum.inductiveautomation.com/t/sql-migration-using-ssma-tables-need-database-reference/17851 "2018-04-27T16:43:31Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![AIO](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/aio/32/87549_2.png) [@AIO](https://forum.inductiveautomation.com/u/AIO)\
**Post date:** [April 27, 2018, 4:43pm UTC](https://forum.inductiveautomation.com/t/sql-migration-using-ssma-tables-need-database-reference/17851/1 "2018-04-27T16:43:31Z")

</div>

Hey folks,

We’re in the midst of a SQL migration from MySQL to MSSQL using the SSMA tool.

However, I’ve found that the tables we migrate, when we query from ignition, they need a database reference (ie: select \* from database.table), whereas if I build that same table using a transaction group, I can use the ‘standard’ query (ie: select \* from table).

Hoping someone can help me understand the mechanism, and possibly help me solve this.

Thanks!

---

<div class="post-metadata">

**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\
**Post date:** [April 27, 2018, 5:03pm UTC](https://forum.inductiveautomation.com/t/sql-migration-using-ssma-tables-need-database-reference/17851/2 "2018-04-27T17:03:45Z")

</div>

Most likely, your migration tool is logging in with different credentials than the gateway, putting unqualified tables in a different schema.

---

<div class="post-metadata">

**Author:** ![AIO](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/aio/32/87549_2.png) [@AIO](https://forum.inductiveautomation.com/u/AIO)\
**Post date:** [April 27, 2018, 5:08pm UTC](https://forum.inductiveautomation.com/t/sql-migration-using-ssma-tables-need-database-reference/17851/3 "2018-04-27T17:08:45Z")

</div>

We’re using the same user credentials between both the gateway and the migration tool. Is that what you mean?

---

<div class="post-metadata">

**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\
**Post date:** [April 27, 2018, 5:10pm UTC](https://forum.inductiveautomation.com/t/sql-migration-using-ssma-tables-need-database-reference/17851/4 "2018-04-27T17:10:39Z")

</div>

> [@AIO](#):
>
> Is that what you mean?

Yes, that's what I meant. And there's no overrides anywhere for schema name?

---

<div class="post-metadata">

**Author:** ![AIO](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/aio/32/87549_2.png) [@AIO](https://forum.inductiveautomation.com/u/AIO)\
**Post date:** [April 27, 2018, 5:13pm UTC](https://forum.inductiveautomation.com/t/sql-migration-using-ssma-tables-need-database-reference/17851/5 "2018-04-27T17:13:17Z")

</div>

I think you identified the issue.

The DB name and the name I assigned the DB in the ignition connection are slightly different.

I’ll verify that this is the issue when I get back to the office. That’s a ‘doh’ moment for sure.

---

<div class="post-metadata">

**Author:** ![AIO](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/aio/32/87549_2.png) [@AIO](https://forum.inductiveautomation.com/u/AIO)\
**Post date:** [May 1, 2018, 4:29am UTC](https://forum.inductiveautomation.com/t/sql-migration-using-ssma-tables-need-database-reference/17851/6 "2018-05-01T04:29:37Z")

</div>

Turns out that using the SSMA tool, a schema is made named the same as the MySQL database youre migrating from. However, it seems as though the default schema is dbo.

Moving all the tables to the dbo schema fixed the addressing.
