We have to work with legacy database and many tables have a column called upsize_ts of datatype timestamp not related to the data stored.
What is its purpose? Is this some sort of rowversion column? Can we delete that column?
I have found, that "upsize_ts" column is created when upgrading MS Access database to MSSQL using Upsizing wizard:
Upsizing is the process of migrating some or all database objects from
a Microsoft Access database (.mdb) to a new or existing Microsoft SQL
Server database or new Microsoft Access project (.adp).
The upsize wizard documentation mentions following:
Timestamp Columns
By default, the Upsizing Wizard creates new columns with the data type of timestamp in SQL Server tables generated from Microsoft Access
tables that contain floating-point (single or double), Memo, or OLE
fields.
Can we delete that column?
This field should not be deleted if database will still be used by MS Access (which is case for our app).
More About Upsizing Wizard:
http://office.microsoft.com/en-us/access-help/use-the-upsizing-wizard-HP005273009.aspx
Is this some sort of rowversion column?
Yes, it is. In versions of SQL Server before 2008, TIMESTAMP is the equivalent to ROWVERSION.
Can we delete that column?
No one can answer that for you - you need to find out if it really is not used anywhere.
Related
I have a table, which I have clicked Edit top 200 rows, as I wish to flip a cell in one of my columns which is smallint from a 0 to a 1. Every time I change the cell's data from a 0 to a 1 it is automatically changed back to a 0.
It seems that all of my columns are immutable in this way, what am I missing so that I can edit data in my sql database table manually for testing? I am using SQL Server Management Studio 17.
When using Microsoft SQL Server Migration Assistant which converts a MySQL database to an MSSQL or Azure Sql database, triggers are generated for you during the migration and added to your SQL tables.
In my case, these were stopping me from updating and inserting to my table, so I deleted them.
I have a database called AQOA_Core with huge amount of data.
I have a newly created database called AQOA_Core1 which is basically empty. I want to write a query to duplicate AQOA_Core to AQOA_Core1 without the data. I guess to be precise I want to create a skeleton of the primary database into the secondary database.
PS: I use Toad for my database operations.
You can use SQL Server Script Wizard for scripting database objects. You can exclude data, and select the database object types you want to include in your script
Please check the SQL Server guide I referenced above,
I hope it helps you
I have an access database that we use for simple reporting solutions, this pulls data from a remote data base through an ODBC link. The data-warehouse provider has recently added a new data field to all of their tables which is formatted as a 'BIGINT'
Access now shows all records as deleted as it cannot deal with the BIGINT linked table.
As the data warehouse will not change their tables is there anyway that I can get the MS-Access to display correctly and ignore the 'BIGINT' field in the table linking?
I am having to work around this at this moment in time by copying the entire data warehouse minus this column to a MYSQL DB daily which is far from ideal...
I cannot for the life of me work this out.
Instead of using a linked table, just write a passthru query in Access. Eventually CONVERT your BigInt into a string or Integer, depending on the contents.
This link suggests loading the data into a local table with a data type of string:
http://social.msdn.microsoft.com/Forums/office/en-US/fb6f99ec-2ed7-487b-ba39-0777a0b44d5f/the-bigint-problem?forum=accessdev
Perhaps consider that MS Access's usefulness is limited here and it may pay to use SQL Server in future as you will continue to run into these kinds of problems. Is there any reason you can't use the datawarehouse directly?
You may also wish to consider using an .ADP (a file type of MS Access) which has a native OLE DB connection to the SQL Server database (no ODBC flimflammery) but also all the usual forms and reports.
ADP's are deprecated but I have had great success with them.
This is an old thread, but you can create a view and cast the bigint as int, and then Access will link to it.
Greg
This is an old thread but:
Casting your bigint as an int as someone has suggested isn't going to work if any of your values in your bigint column are bigger than the maximum value for an int (and if none of them are bigger than the max value for an int, it makes you wonder why a bigint is being used in the first place).
MS Access (from Access 2000 onward) does have a decimal data type, which is good for numbers of up to the maximum size of a SQL Server bigint and more. So if you make your MS Access field to be of type decimal, it can handle anything a SQL Server bigint can throw at it. In your process of taking the data from the SQL Server database into your MS Access database you would need something done programatically along the way to slurp your bigint values from SQL Server and squirt them into MS Access as decimal
Is there any way to populate TCP-H database for Microsoft SQL Server 2008.
TPC-H provides a DBGEN tool that can create huge tables according to a schema. By default, it generates text files (one per table) with tuples represented in lines and '|' separating the columns in a tuple and new line for the tuple end.
I need that huge table to be imported in SQL Server 2008.
This is the method.
I am coding ib Visual Basic. I need to store the current system time in MS Access timestamp field. How do I go about it.
Dim row As DataRow = ds.Tables("StudentTable").NewRow
row("SSMA_TimeStamp") = System.DateTime.Now.ToString()
The field name starting with SSMA makes me think that his is a SQL Server table and that its been upsized from Access using the SQL Server Migration Assistant for Access If so Access isn't involved here at all.
If this is indeed the case then it's almost certainly a SQL Server TimeStamp aka RowVersion column which is not updatable by users or code. It is a special field that changes only when data in the row changes. This makes a lot less work for Access (and other programs if they use it) to see if the row has been changed elsewhere when Access goes to update the data. Read up on it in Books Online.