Why do we need to delete tables to relink them? - sql-server

Question

I am using this code to attach DSN less table.
'//Name : AttachDSNLessTable
'//Purpose : Create a linked table to SQL Server without using a DSN
'//Parameters
'// stLocalTableName: Name of the table that you are creating in the current database
'// stRemoteTableName: Name of the table that you are linking to on the SQL Server database
'// stServer: Name of the SQL Server that you are linking to
'// stDatabase: Name of the SQL Server database that you are linking to
'// stUsername: Name of the SQL Server user who can connect to SQL Server, leave blank to use a Trusted Connection
'// stPassword: SQL Server user password
Function AttachDSNLessTable(stLocalTableName As String, stRemoteTableName As String, stServer As String, stDatabase As String, Optional stUsername As String, Optional stPassword As String)
On Error GoTo AttachDSNLessTable_Err
Dim td As TableDef
Dim stConnect As String
For Each td In CurrentDb.TableDefs
If td.Name = stLocalTableName Then
CurrentDb.TableDefs.Delete stLocalTableName
End If
Next
If Len(stUsername) = 0 Then
'//Use trusted authentication if stUsername is not supplied.
stConnect = "ODBC;DRIVER=SQL Server;SERVER=" & stServer & ";DATABASE=" & stDatabase & ";Trusted_Connection=Yes"
Else
'//WARNING: This will save the username and the password with the linked table information.
stConnect = "ODBC;DRIVER=SQL Server;SERVER=" & stServer & ";DATABASE=" & stDatabase & ";UID=" & stUsername & ";PWD=" & stPassword
End If
Set td = CurrentDb.CreateTableDef(stLocalTableName, dbAttachSavePWD, stRemoteTableName, stConnect)
CurrentDb.TableDefs.Append td
AttachDSNLessTable = True
Exit Function
AttachDSNLessTable_Err:
AttachDSNLessTable = False
MsgBox "AttachDSNLessTable encountered an unexpected error: " & Err.Description
End Function
Suppose I changed a schema of a linked tables using ADO:
cn.execute "Alter table table 1 add add Name string not null"
I know this will change the table in SQL Server.
I thought that the linked tables in MS Access always reflected any changes made to the tables in SQL Server. Why do we need to delete the local table and relink it to reflect the schema changes?

Answer 1

The simple answer is that schema changes only are saved and gathered at link time for reasons of performance.
The linked table has no way really of knowing that the table structure has been changed until such time you tell Access to check (by simply refreshing the table).
I mean, when you are on a web page, they might add some new articles, or change the layout. The web server does not then call out to everyone on the internet and tell them that page has been updated. Seems like a silly approach.
The table structure is pulled at linking time. If every time you touched or used a table then performance would take a big hit, and lots of extra checking, chatter and communication with the server would have to occur.
If the linked table did not save information about the schema local, then you would not have this issue.
However, linking to a table not only saves connection information, but it also saves the information about the table structure.
Pulling data from a table is a spectacular and massive difference of an issue then asking sql server to send down the whole table structure. (And so what if it did – you would STILL THEN have to update the local information).
I mean, my form might have 2 fields out of 150 fields. Why would I want all that mass of information to come down the network pipe just to display two text boxes on a form? Why should 150 columns of information (name, length, data type, Auto number etc., indexing come down each time?
Have you seen the propriety sheet for each column on sql? It quite a large bit of information. In fact that information is quite a bit of data when you have 100 or more columns. The information sent down the network pipe would be MORE than the data contained in the one small record you are editing!!!
I mean, you might link to a view on sql server that only includes a few columns. Each query and use of that view will thus only pull the columns defined at view time.
In fact, even other views on sql server can have a hard time being updated when you modify a view. As a result even query on queries (views on views) EVEN when using pure sql server often need to be to “tell” that the data structure and columns you originally started out with are changed.
So linked tables in Access are not much different then saved views on sql server. If you update the base tables, then you have to execute a sp_refeshview command on sql server to update the view to know about these changes.
I mean, if you grab a word document from the server, and others start modify the copy on the server, does each work station know about the changes? Does the server reach out now?
So the information about the schema is persisted at link time, and the re-creating and building of the schema does not occur by just “using” the linked table. You have tell access to re-load the schema when changes are made.
Having to check the schema, and update the information in access for each record or each time you grab some data is a costly and time consuming process.
Since for 99.9% of your data pulling, the schema is not changing, so having all that overhead of pulling and testing the schema each time does not make much of any sense (it would be a poor idea and design).
As pointed out, even when not using Access, and using views on sql server that point to existing tables, the schema is persisted in that view until such time you refresh that view.
And this issue and problem certainly not limited to Access to Access back end, or Access to sql server back ends. Most database products simply don’t out of the blue update things like views that persist the original schema for reasons of performance.
I mean, I am on an access form, and I move to the next record. Are you telling me now that Access should start talking to the server and asking if the schema was changed? Makes no sense at all force the client to gather all that information and re-save the schema information.
I suppose perhaps on each first table use for a given session Access could query for this information, but really, what about all the users currently working? They not see the schema change anyway.
Schema changes are also rather rare. If they are frequent, then something is wrong with the developers - not the database system