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.
Related
I'm trying to compare MS Access SQL queries for local table vs linked table
(it is linked to an Oracle and to a SQL Server database).
I can get query duration when running the SQL command directly on Oracle or SQL Server, but when running the SQL in MS Access, I don't know how to capture the query duration.
Is there a way to get the query duration when running a SQL command inside MS Access?
Thanks. :-)
Yes, it is.
Record in a variable the actual time.
Create a recordset with data source pointing to your query/view/table
Open the recordset (eventually you may check the recordcount)
Record in another variable the actual time
DateDiff between 1. amd 4.
Access does not provide that sort of information, unlike server databases.
You could use a Form Timer and get an idea of the duration, but with linked tables a lot of that depends on the network, server overhead, etc.
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
This is pretty new to me. I have an Access database that I was to upsize to a SQL server but to keep the Access front end to make this application available remotely. I have imported the data in the SQL database using SSMA which looks to be fine. However, when adding a new record to the Access frontend, the SQL server is not being updated. Am I missing something? I (think I) have linked the tables together but still not joy.
Any help would be great. Thank you
If the data is being stored, but not on the SQL Server then you almost certainly have not linked the tables correctly.
On your Access front end your starting point should be no tables (unless you have some tables deliberately reserved for the front end for some reason). You then link to the back end tables (because you said 'linked the tables together', I suspect you have copies of the tables still in your front end).
During the linking process, Access will confirm if each link is established successfully.
It sounds like you haven't imported the data from MS Access to SQL yet.
Check out the SQL Server Migration Assistant(SSMA) on how to do that.
http://www.microsoft.com/sqlserver/en/us/product-info/migration-tool.aspx#Access.
First you need to migrate the data to SQL and then you link the data in SQL to MS-Access.
Once the tables are linked appropriately it will update in SQL as it is entered in Access.
To link the tables you need to first setup an ODBC and then in access select external data -> import -> more -> ODBC Database and select "Link to the data source by creating linked tables"
Check out this link: http://www.fontstuff.com/ebooks/free/fsLinkingToSQLServer.pdf to make sure you did it right.
I had this problem before.
Create a primary key for every table you want to edit in Access. set identity specification and Identity increment by 1 or ? (you can find this setting in column properties) Make sure data type for primary key is int.
All boolean value fields should have constraint set to 0 and no null values.
Is it possible to search and replace all occurrences of a string in all columns in all tables of a database? I use Microsoft SQL Server.
Not easily, though I can thing of two ways to do it:
Write a series of stored procedures that identify all varchar and text columns of all tables, and generate individual update statements for each column of each table of the form "UPDATE foo SET BAR = REPLACE(BAR,'foobar','quux')". This will probably involve a lot of queries against the system tables, with a lot of experimentation -- Microsoft doesn't go out of its way to document this stuff.
Export the entire database to a single text file, do a search/replace on that, and then re-import the entire database. Given that you're using MS SQL Server, this is actually the easier approach. Microsoft created the Microsoft SQL Server Database Publishing Wizard for other reasons, but it makes a fine tool for exporting all of the tables of a SQL Server database as a text file containing pure SQL DDL and DML. Run the tool to export all of the tables for a database, edit the resulting file as you need, and then feed the file back to sqlcmd to recreate the database.
Given a choice, I'd use the second method, as long as the DPW works with your version of SQL Server. The last time I used the tool, it met my needs (MS SQL Server 2000 / 2005) but it had some quirks when working with database Roles.
In MySQL, you can do it very easily like this:
update [table_name] set [field_name] = replace([field_name],'[string_to_find]','[string_to_replace]');
I have personally tested this successfully on a production server.
Example:
update users set vct_filesneeded = replace(vct_filesneeded,'.avi','.ai');
Ref: http://www.mediacollege.com/computer/database/mysql/find-replace.html
A good starting point for writing such a query is the "Search all columns in all the tables in a database for a specific value" stored procedure. The full code is at the link (not trivial, but copy/paste it and use it, it just works).
From there on it's relatively trivial to amend the code to do a replace of the found values.
I have written SQL statements (stored in a text document) that load data into a SQL Server database. These statements need to be repeated daily. Some of the statements use the NewId() function to populate a keyed field in the database, and this works fine.
While I'm in the process of writing an application to replicate these statements, I want to use Access queries and macros instead of copying and pasting queries into SQL Server, thus saving me time on a daily basis. All is working fine but I can't find any function that will replace the SQL Server NewId() function. Does one exist or is there a work around?
I'm using SQL Server 2005 and Access 2007.
On top of matt's answer, you could simply use a pass-through query and just use your existing, working queries from MS Access.
A solution would be to insert the stguidgen() function in your code, as you can find it here: http://trigeminal.fmsinc.com/code/guids.bas https://web.archive.org/web/20190129105748/http://trigeminal.fmsinc.com/code/guids.bas
The only workaround I can think of would be to define the column in your access database of type "Replication ID" and make it an autonumber field. That will automatically generate a unique GUID for each row and you won't need to use newid() at all. In SQL server, you would just make the default value for the column "newid()".
Again, there seems to be confusion here.
If I'm understanding correctly:
You have an Access front end.
You have a SQL Server 2005 back end.
What you need is the ability to generate the GUID in the SQL Server table. So, answers taht suggest adding an AutoNumber field of type ReplicationID in Access aren't going to help, as the table isn't a Jet table, but a SQL Server table.
The SQL can certainly be executed as a passthrough query, which will hand off everything to the SQL Server for processing, but I wonder why there isn't a default value for this field in SQL Server? Can SQL Server 2005 tables not have NewId() as the default value? Or is there some other method for having a field populate with a new GUID? I seem to recall something about using GUIDs and marking them "not for replication" (I don't have access to a SQL Server right at the moment to look this up).
Seems to me it's better to let the database engine do this kind of thing, rather than executing a function in your SQL to do it, but perhaps someone can enlighten me on why I'm wrong on that.