I have a column named Lastmodified, with a data type of Date, but it should have been DateTime.
Is there any way of converting the column?
When I use the 'Design' feature of SQL Server Management Studio I get the following error:
Saving changes is not permitted. The changes you have made require the following
table to be dropped and re-created.
Not really interested in dropping the table, I just want to know if it is possible to convert a column from Date to Datetime or do I have to delete the column and create a new one with the correct data type?
It shouldn't need to drop the table and recreate it, unless that column is taking part in one or more constraints.
You can just do it using SQL:
ALTER TABLE Tab ALTER COLUMN LastModified datetime2 not null
(I chose datetime2 over datetime, since the former is recommended for all new development work, and since the column is currently date, I know you're on SQL Server 2008 or later)
That's just a safety setting in SQL Server Mgmt Studio - you can turn it off, if you're adventurous :-)
Disable the checkbox there and you can do whatever you like!
You can't change the type of a column in place. You need to create a new column, copy of the values over, and then drop the original column.
SQL Management Studio usually accomplishes this by creating a temporary table with the new column name, copying the values over, dropping the original table with the old column, and then renaming the new temporary table to the new name. Often it does this without people even realizing it.
However, this can be a very invasive approach, especially if you already have a lot of rows in the table, so you may want to just write a SQL script add the new column to the table, copy the values over, drop the original column, and then use sp_rename to change the new temporary column name back to the original column name. This is the same idea as what SQL Management Studio is doing, except they are dropping and recreating the whole table, and you are just dropping and recreating the column.
However, if you DO want to let SQL Manangement Studio do it this way, you can turn off that error message. I believe it was originally added because people did not wantdrop and recreate the table by default. To turn this message off, go to Tools->Options-?Designers, and uncheck the "Prevent saving changes that require table re-creation", then you should be able to save your changes in the designer.
Related
In MS Access, I have a few tables with some column names having spaces in their column names (e.g. Transaction I).
I need to replace the spaces with underscores (e.g. Transaction_ID) using SQL.
Although I'm somewhat familiar with SQL, however, my exposure was in an Oracle environment and all of those queries and functions don't work in MS Access. I am fairly new to MS Access.
I have tried following codes from the posts that I searched, however, to no avail.
alter table EP sp_rename 'Transaction ID' to Transaction_ID
alter table EP rename column 'Transaction ID' to Transaction_ID
Access does not have a built in command "line" option to re-name a column.
(and your example looks to be for SQL Server, and MORE so it looks to be using a library stored procedure function to do this for you. So, that looks to be SQL Server syntax - not MS Access.
If you going to use DDL in Access to re-name a column? You have to create a new column with the desired name, and then move the data to this new column, and then drop the old column.
The so called sql 'ddl' commands in Access actually do quite much follow the SQL standard.
So, before embarking on this road, I would consider to use the built in GUI + table designer. (It will do the dirty work behind the scenes for you).
So, can you use DDL to rename a column? Yes, but you have to do this in 3 steps.
Create the new column.
Copy data from old column to new column
Delete the old column.
Because of indexing, possible relationships and other issues, then one REALLY does want to use the built in table designer + the GUI here.
But, you can use say a procedure (VBA) in Access to do this:
Say we had a REALLY bad column name for City called [The City].
To re-name to City, then we can go:
Sub MyAlter()
' create the new column
CurrentDb.Execute "ALTER TABLE tblHotels ADD COLUMN City TEXT(50)", dbFailOnError
' copy the data
CurrentDb.Execute "UPDATE tblHotels SET City = [The City]", dbFailOnError
' drop the origonal column
CurrentDb.Execute "ALTER TABLE tblHotels DROP COLUMN [The City]", dbFailOnError
End Sub
Just keep in mind that ANY column in Access with spaces (yuk!!) needs to be surrounded with []. This applies to SQL select queries, update queries, insert queries, and of course DDL commands to modify the table structure.
If a one-time deal, then of course simply use access, open the table(s) in question in design mode, and make the changes.
However, if you do for some reason do need to use a procedure, then the above code in a access code module can be used.
Or you could just fire up the query builder, flip to SQL view mode, and type in the above raw sql that way.
(you have to type in each sql command separately - the Access query builder only allows ONE SQL statement at a time.
So you could type in first above SQL, hit "!" to execute, and then do the two additional SQL statements.
MAKE A BACK-UP!!!
And of course any code, any queries, any reports etc. that used the old column name will break. So changing column names in an existing application is a HIGH RISK adventure (you can and will break tons of code, existing forms, and existing reports, and existing SQL queries you have now).
However, if this is a one-time update? Then I would of course just use the table designer. It allows a re-name without a column drop – and it keeps other field settings such as indexes, format etc.
I which above suggested approach makes the most sense will depend on your particular "use" case.
Last but not least? You can use VBA code and the table objects in that code. This approach is probably the best. It does not use SQL DDL, and you have greater control over a lot of features for a given column (required, allow nulls – the list goes on). Most of these settings CAN be set in DDL - but you spend quite a bit of time searching and looking up those settings.
All in all? I would use the table designer if possible here.
I have a query for a report based on an MS Access database (as the program project file). The tables in this database get updated with new fields periodically as new features are added.
We need to be able to support old and new versions of the file for our report, so need to know if there is a way to insert a field into the SQL SELECT query if it does not already exist. (Note: Do not want to create ALTER TABLE type statements, as the field only needs to be added into the result set, not into the table permanently.)
I know you can do something like "" AS [FieldName], but that only applies when you know the field doesn't exist and need to create a blank spot for it (such as when a unioned table does have that field). In this case, the table might have the field so I want to use it if it does, but if it doesn't I want to have it still exist in the query results with a default value.
Any help would be appreciated. (I also know you can force the user to update the file, but that option was stated as "only last resort".)
Thanks,
Chris
I am trying to create a computed column after a specified column.
But the SQL gives syntax error for the query below. Please help me with the correct syntax/way to do this.
ALTER TABLE service_ServiceClass
ADD LichenClassName AS ([dbo].[UfnGetServiceClassName]([Id])) AFTER Description
You get an error because "AFTER" is MySQL syntax.
There is no direct way to alter column order in SQL Server currently.
In MS SQL Server Management Studio, you'd have to use the SSMS Table Designer (rightclick yourTable->Design) to arrange your columns, which can then generate a script which drops and recreates the table.
There is no after clause in sql server's alter table statement.
The order of the columns in the table (as well is the order of the rows, btw) is completely insignificant from a user's point of view.
It's significant from the server point of view, as it may effect performance when using clustered indexes.
The only time the order of the columns matters is when you are using select * ..., but you shouldn't use that anyway. Always specify the column names directly.
My scenario:
I can change the ordinal position of a column in a table.Is there a way to change the ordinal position of a column in a table without recreating the table?
No, you have to recreate the table if you wish to achieve this. (SQL SERVER)
Even when you do this in SSMS, you will see that the script that is generated also recreates the table.
Not in SQL Server - Not sure about other RDBMSs.
You can create a View with the desired ordinal positions but the only time I can think that would be useful is if you are using SELECT * which is a practice that should be avoided anyway.
Hi it depends on the database system you use.
For example in some it is possible to remove and add a column and you can do it in a procedure part where you also can refill it.
But in general it shouldn't matter as you can define the returned data order in your select statement. Is not that enough for you?
Without recreating the Table is Not possible. However, if your concern is about loosing the data here is an option provided by SQl Server Management Studio.
Note: I have used Sql Server 2019 Developer Edition.
Right Click on the Table name and Choose Design Option
Using your Cursor Drag the position of your Column to your desired Position
SQlServer Table Design Options
If you want to do it at script level, You can see the idea below provided by SSMS
Enable the "Auto Generate Change Script" Option available in Tools Menu --> Options --> Designers --> Table and Database Designers.
Enabling the Auto Generate Change Script Option
When you drag the Column in SSMS it will automatically creates the Script for you.
The High level Idea in the auto generated Script is,
Creating a Table with Temp_YourTableName with desired Order of Columns
Copying all the Data from the Original Table to new Temp_YourTableName
Drop the Original Table
Renaming the Temp_YourTableName to Original YourTableName
of course doing everything with Transaction scope to avoid any data loss while the script is executing.
I found a good reason why some time we need to do this here. Interestingly, it is based on Context and not to do anything with Technical.
Say for example, Original Address Table Contains, Street Address 1, City, State, Zip and Country columns. If the requirement Changes to include a new Columns like Street Address 2 this would be meaning full.
Does anyone have an idea what this error means or how to solve it? I am using Access 2003 and SQL2005. It comes up when trying to add a record on a particular subform.
[Microsoft][SQL Native Client] Invalid character value for cast specification (#0)
This MS bug report describes the same message, but it is a bug in SQL Server 6.5 that has already been solved.
Solved: Apparently having no PK on the destination table was causing this, it didn't have anything to do with the subform or the query from Access. I wasn't even aware there were tables in this database without PK. Adding PK to the destination table solved it. The strange thing is the same query string that errored when executed via SQL native client, executed through SSMS with no errors. Hope this helps anyone else who has come across that strange message.
Hum, I would check the text box default on the access side. I would also bring up the linked table in design mode, and you want to check the data type that ms-access assumes here. For non supported data types ms-access will generally use a string, and sql server might be wanting something else.
So, check both the Primary key (PK) in main table, and then check the data type used (assumed) in the child table for the foreign key (FK) column. While we are at this, check your expressions used for the child/master link settings in the sub-form control (not the form, not the sub-form, but the sub-form control used in your form that links up these two tables).
Sub forms in access are sensitive if you don’t have a timestamp column in the sql server table. As mentioned check the PK and the FK data types and make sure they match up (just bring up the tables in design mode in ms-access -- you get an error message about the design mode being read only, but just continue on so you can check/view to ensure the data types match up).
So for the child table, you need a PK, a FK, and also a timestamp column (you don’t have to display the TS column in the sub-form, but you need it in the table).
Sub-forms in ms-access are sensitive and often fail if you don’t include a timestamp column in the sql table. (access uses these row version columns to determine if the data been changed).
Is one of your fields in the view calculated/built with the CAST function? In this case, you might not have the right to update/add a value for that field.
Can you execute your view in the MS SQL Studio interface and try to insert a record?
Another cause to this issue is that if you change a table name without alterting the view then the "Dependencies" of that view still remians with the table old name.
Let say I have a table 'A' and a view 'Av' which derives from 'A', and I created a new Table which will be named 'A' and I changed 'A's name to 'A_old' but I didn't executed an ALTER VIEW, so the dependencies of 'Av' still remain on 'A_old' but the view is derives from 'A' and it cuasing this Error in Access when trying to open the view as a linked table
I just spent a day battling this with an Access ADP project that was imported into a new Access 2016 ACCDB file. Initially I figured it was an issue with the application code, but I was getting this keying records directly into the table. Interestingly, the records always got written - it seemed to be the read-back that was triggering the error. Profiling the insert sql and running that from SQL Management Studio worked without any issues.
The table that was causing the problems had a GUID Primary Key. Switching that to an int column resolved the issue.
The SQL database was also littered with a few thousand extended properties which I removed before switching the PK. There was a strong suggestion from the web that these cause problems. The source of that process is documented here: Remove All SQL Extended Properties
I had this problem with Access 2016 trying to update an ODBC linked sQL Server database. Problem was a null value in field used to join the two tables. Eliminating the null value solved the problem
OK I just had this bad experience and it had nothing to do with PK or any of this stuff in my situation. The view that reported this problem in Access was created in SQL Server originally and used a CAST of DATETIME to plain old DATE to get rid of the unneeded time part. Up until today this view had caused 0 issues in Access, but started to generate heartburn just as described above.
So, I generated a Drop/Create script for the MSS view, ran it, relinked the views in Access, and the Access database was happy with the result. All my so-called tables in Access are basically views through links to MSS for reporting. I only have 1 table that actually does changes. Other than that, I do not edit through views in Access.
The message is of course useless as usual but this was my solution in my situation.
Based solely in the message you provided above, it appears that you are trying to set an invalid value to some field or parameter, etc... The message is telling you that it is trying to convert a value into an specific data type but the value is invalid for that data type... makes sense?
Please add more details so we can help you better.