Why does SQL server 2008 always warn about needing to drop tables to rename columns? I was under impression this was not required unless it was a key. If I change a column from null to not null even if is not a key field it wants to drop table and all relations.
If you're editing the table in the designer then it's the designer that is being pedantic. Try changing (unchecking) these options:
Tools > Designers > Prevent saving changes that require table re-creation
The designer still throws an warning dialog after unchecking that but there is also this option to uncheck:
Tools > Designers > Warn about tables affected
I believe the reason the designer has to drop tables to rename columns is because there is no SQL command to do that, and what it does instead is copy the table's data into a temp table, drop the table, create a new table with the altered column name and copy the data into it.
Related
I have a typical Access front-end with SQL Server back-end. I created some views in SQL Server and linked to them in Access. When I use "CREATE INDEX index_name ON view_name (field_name)" it creates a primary key even though I have not specified it to do so (and do not want it to do so). Why is that? and how can I create a non-primary key index?
How this works?
Any view, any linked table, in fact ANYTHING you hit, use, consume from SQLServer?
All indexing is setup 100% in SQLServer. The Access client side does not, cannot, and WILL not create any kind of index for you.
The create index command to specify and setup a primary key? It does not really create an index in Access but ONLY SETS and TELLS Access what PK to use.
In fact, when you link to a view, you are prompted to select the PK when linking to a view.
SQLServer views DO NOT have the concept or even a setting that tells you or EVEN LETS you specify the PK column. Part of the reason for this is in fact that a view can consist of more than one table - so which table now is to define the primary key. And in fact if your view has a join with say 5 tables? Then in fact that view has 5 different primary keys from 5 different tables).
So, when you link to a view in access, you will note this prompt:
If you don't select a column for the pk?
Then you have no PK set. However, you can use VBA to TELL ACCESS what row to be the PK setting.
So, say in above I did not select a PK when linking with the GUI. Or say I am using code to link to a view?
Then in code to set the PK value, I would and could and should execute the following command:
CurrentDb.Execute "CREATE UNIQUE INDEX IXPK ON dbo_ViewHotelsTest (ID) WITH PRIMARY"
AGAIN: Note above comments. The create unique index DOES NOT create an index in Access. Nor does it create an index on SQLServer. That command is how you can tell Access which column is to be seen and treated as the PK.
So, above command?
In plain English:
Please Mr. Access, will you set the PK column and we are using the above
command to do this.
In other words, there is no other command in code to "tell" Access what the PK is supposed to be, so the DDL sql create index command is used. But I STRESS AGAIN THIS does NOT really create an index, but ONLY tell Access what column to use as the PK.
This command results in the SAME and IDENTICAL results if you select a PK during a linking of a view.
If you want to create an index in SQLServer? Then go to SQLServer, and create your index(es) in SQLServer.
FYI:
As a further explanation, in 99% of cases you NEVER want, nor need, or even should even create an index on a view on the SQLServer side of things.
In EVERY case, if the base table used for the source of the view has an index that can be used, it WILL IN ALL cases be used if you build an on-the-fly query, build a SQLServer side view, or even create a sql stored procedure. IN ALL cases, a simple create of an index on the base source table (using SQLServer tools) will suffice, and in ALL cases, include views, and including linked view from Access will automatic use ANY and ALL existing indexes on the base table from SQLServer.
So, not only is there zero requirements to EVER try and create an index in Access on linked tables (or linked views), but in fact it not even possible. Of course the create index command DOES need to be used to set the PK column when linking to a view.
If you link to table, then Access can figure out which column is the PK, and will set this for you. But SQLServer does not have a setting, nor even the concept of a PK column for a view, and thus you have to select the PK during linking using the GUI, or as noted, you can in code execute the above command that tells access which column to use as the PK, and as noted, that command does not in fact even create an index, but that command is ONLY to tell Access client side which column to see/use as the PK.
You can for views that don't require you to "update" the data. So, a linked view without you selecting (or better said "setting") the PK column will be read only.
So, if you using the view for a combo box, or say just a report? Then you don't care, and don't need to set the PK for that view, and it will be "read only". So this means that you ONLY need to set the PK column for a view if you need to update that view (say in place of updating the base table that the view is based on).
So, in summary:
that create index command does not actually create an index.
That create index command is ONLY required if you need a linked view that allows Access client side to update such views. Without the setting, then the linked view will be read only. So the purpose, the act, the role, the "thing" that create index does on the linked view? It is ONLY to tell Access what column is to be used for the PK - it does not actually create an index anywhere - including NOT creating one in Access client side. (So, ONLY purpose is for TELLING access which column to use for the PK. Can't really say why they use that command that way but best guess was no other way existed to tell Access what column to use for the PK - so we use that command).
If you use the linked table manager, and re-fresh the table links? Access WILL remember the PK settings for a view. However, if during linking you change the database that the linked tables point to? Then the PK settings in views will be lost during that re-linking process. (and then you have to re-execute those commands to re-tell Access which column in the linked view is to be seen/used as PK column.
You don't need to ever create an index client side for Access in regards to linked tables, or views - all indexing is automatic, and if an index exists on the server table, it will and can be used.
So, create index command is HOW you setup a PK column for linked views. In all other cases (linked tables - but not a view), then that command is not required, and ANY and all existing indexes that exist and were created on the server side table will be used (and thus no need to try or create an index in Access, since all such indexes are handled by the server side - Access has no say, nor even control over how SQLServer uses indexes). But, a correct use of index on a SQLServer table will automatically be used by Access in the requests it makes to SQLServer. But that "job" of indexing is 100% managed by the server - not Access.
Everytime I enter data into one of the SQL linked tables, some of the rows keep saying #deleted no matter what I do. The data is fine in the actual SQL server but not within Access. I never have used Access before so I have no idea what I'm doing. Please use the most non-tech savy dialog as possible... This is all so new to me and I am not good with technology at all.
I have tried refreshing the tables by going to the "Linked Table Manager" thing but that hasn't helped. I tried completely deleting the data from both Access and the SQL Server, re-entering it into the SQL server, and creating a new linked table within Access. I have tried exporting the data into Excel from the server and importing it into Access. None of it has worked. It's only the first 10 rows of data though... The rest of the table is completely fine and all the data has similar structure so I don't know why only the first 10 rows are being affected.
Ok, there are 3 things that often cause this.
1 - Make sure the sql table has a PK column. This is often (useally) a autonumber (incrementing by 1 integer column). So when you create the column in sql server, set it as primry key (a button in the menu can be hit to set PK using the sql manager). Then change in the property sheet the column to identify "yes" and it will set the starting number (1) and the increment (1) for you. Now add the other columns.
So Access needs a PK column.
If above was not your issue, then next up that is common is if you have a "bit" column in sql eerver. These can't be null, or access goes crazy. so if you have a bit column, then MAKE sure you set the default for that in the sql table designer as (0).
If the above don't fix your issue? Then number 3 on the list is to add what is called a row version column to the sql table. Simply add a timestamp column (this is NOT a date column, but is a time stamp row).
In ALL of the above cases, after you make the change to the sql server table, you have to re-link the access table. It is sufficient to right click on the table in Access, choose linked table manager, and then check box the table in queston, and hit ok. The link will be refreshed for you.
So the above are the 3 main issues. In most cases, the PK is the issue. However, if the table on SQL also has a trigger (that inserts) to other tables, then that table trigger has to be changed - but lets take this 1 step and soluion at a time.
As a general rule, Access needs a PK column when working with sql server. If you have that, then check the null "bit" issue - sql server tables need a default setting of 0 for those columns, and if they are null, then Access don't like that.
If both above issues are NOT your issue, then adding a column of timestamp to the sql table will fix this.
I created a model from a database schema's tables. It's working correctly, but when I rename a column in a table and after that I sync to the server. Navicat recognize the changes and show the SQL queries which needed to be executed. The queries are the following:
disable foreign key checks
drop indexes
create column with new name
drop old column
recreate previously dropped indexes with the currently created column
enable foreign key checks
How can I force Navicat to not drop columns, just rename them?
Thanks in advance, kukko.
Have a look at object editors in dbForge Studio for MySQL. There is possibility to rename the field with dependent object modifications.
Here it is another simple way to rename the column:
select column in Database Explorer
press F2 (Rename command) and enter new name
choose Rename or Refactor (with dependent objects modifications)
By simply executing the statement to rename the column:
ALTER TABLE your_tablename CHANGE column_name new_name datatype other_options_like_nullable;
For example:
ALTER TABLE myTable CHANGE badname newname INT NOT NULL DEFAULT 0;
I have created a local database db.mdf in VS2010 asp.net website. In there are a few tables.
Now I need to rename the tables. But query designer doesn't let me. How do I rename those tables?
In Server Explorer, right-click the table you want to rename and choose Open Table Definition from the shortcut menu.
The table opens in the Table Definition window of Table Designer.
2. Right-click the table in the Table Definition window and choose Properties from the shortcut menu.
3. In the field for the Name value in the Properties window, type a new name for the table.
To cancel this action, press the ESC key before leaving this field.
From the File menu choose Save table name.
Rename database tables in Visual Studio:
Server Explorer
Right click on the tables
Click the Edit Table Schema
The answers did not work for me in Visual Studio 2017. The Table field is locked for some reason.
What worked for me is the following. In the T-SQL tab change the entry
CREATE TABLE [dbo].[Table] (
to
CREATE TABLE [dbo].[NewTableName] (
Then select Update (top-left). It worked for me.
Is there a way in SQL server to generate a script to re-create all the foreign key constraints and relationships? Basically I need to delete all relationships and then need to re-script them against the database.
Thanks in advance
For MS SQL Server here you have a full script with details and comments. And also you can use the SMSS to generate a create script of a table with all its necesary details. But this will do the work for only one table, if you need to do it for all tables and there are a lot, it could be a pain right there.
For MySQL, in case you needed it check this link
In SQL Server Management Studio, you can select see your tables. You can walk through 1 by 1. Press right click on the table -> Script Table As -> DROP And CREATE TO.
With this the Studio will generate the drop constraints and alter table add constraints in a new query window.