I have the following VBA code line:
Set td = CurrentDb.CreateTableDef(strLocalTableName, dbAttachSavePWD, strRemoteTableName, strConnect)
strLocalTableName = "dbo_Contact"
td.Name = "dbo.Contact"
The functionCurrentDb.CreateTableDef changes a "_" in a "."
This doesn't occur on a collegues computer.
What can be wrong on my computer?
If you can provide a reliable, reproducible scenario in which this occurs, please do so at the link Philipp provided.
Also, in case you might not be aware of the reason for the "dbo_" prefix in the first place, here's a quick overview.
SQL Server organizes tables into containers called "Schema". Tables are stored within one of those schemas. The default schema is "dbo"; all new user tables are created in dbo unless you specifically create a different one and put the table(s) in that different schema.
For example, the short-lived Access Web Apps tables, which were created in SQL Azure, were in one of three schemas called "Access" , "AccessExternal" and "AccessSystem"; none were in the default dbo schema. In the Access side, we probably didn't even know that in a lot of cases.
Access doesn't have schemas, of course, but it does need to identify the location of the linked tables according to which SQL Server schema they are in. It can't do that with the schema.tablename format. It converts the names to the schema_tablename format instead. Hence, we see, by default, dbo_YourTableNameGoesHere. Because the same SQL Server database can have two tables with the same name, but in different schemas, Access needs to disambiguate those names by creating the prefixes for them. It also does that with the default dbo_, although that's not strictly necessary when there is only the one, default, schema.
The tricky part is that you can alias a linked table name to be virtually anything you want, as long as it's a valid table name. So, to keep things simple, many Access developers rename their linked tables, dropping the "dbo_" prefix so the table names are consistent with the pre-migration tables.
All in all, what we are now seeing appears to be related to some unsuccessful attempt to "manage" that process during relinking.
