Does anyone know of ANY way to query a Sql Server 2000 database to find out when tables were last modified please?
It is unfortunately not stored in SQL 2000 unless you have custom columns storing that type of data for the table. So if you are looking for something built into SQL Server you are sadly out of luck.
Related
So I have a DAX query that I have built in SSAS. But since my application like DAX, I thought pushing the set of DAX results to a database server table would be the ideal solution for my application to read.
How do I output the contents of a DAX query to a SQL Server database table? And if possible truncate the contents of the table before each run?
I'm using SQL Server 2016 if that helps.
I got around this by using a linked server to output the contents of an 'open query' to a table variable in SQL.
I am querying a sql 2000 database on a sql 2008 database (linked server) and in the linked server i have a data with accents in. However when i query the 2008 database the accents appear correctly and as expected. But when i run the query on sql 2000 database the data is not showing correctly.
SQL 2000 Collation - SQL_Latin1_General_CP1_CI_AS
SQL 2008 Collation - SQL_Latin1_General_CP850_BIN2
I have attempted to add "COLLATE" to my queries however it is just not showing the data correctly.
Any ideas?
Thank you.
It turned out the issue was that the data types for the columns were varchar when they needed to be nvarchar. By dropping the table and recreating it with the correct data type this resolved my issue.
I'm about to write my first procedure to check if yesterdays data exists in one database, and if it select some of the data, use a count and insert that data into another database. If the data doesn't exist, then send me an email.
I'm using SQL Server 2005 and I'd like to ask the community for tips or good starting knowledge on smart procedure coding.
Thanks!
Here is an article on MSDN about stored procedures on SQL Serve 2005 that should help.
i have a view that is using linked server to retrieve data from a remote server in SQL Server. On each time viewing the view, the results returned are vary. For example, 1st time execution may return 100 rows of records but on 2nd time of execution, rows returned are 120 rows. Any ideas what is the cause?
I have witnessed odd linked-server results that are a product of non-determinism written into the SQL itself, I.e. a TOP query written without an ORDER BY clause.
This problem, for example, where the chap had multiple non-unique foreign keys coming from a table source on the left hand side of a linked-server INNER JOIN, and wanted 10 rows from a remote sub-query to the right, where the end result was restricted to 10 rows itself, when it should have been greater than 10 rows.
Should definitely give your SQL a quick eye for such curiosities.
The data on the linked server changed between executions?
Is your SQL Server fully patched? SQL Server 2008 and 2005 both have bug fixes out related to incorrect query results from linked servers.
Here is one example:
969997 FIX: You receive an incorrect result when you query data from a linked server that is created by using an index OLE DB provider in SQL Server 2005 or in SQL Server 2008
Is the linked server also a SQL Server? If not, perhaps a buggy driver? I've seen odd results, for example, due to an old Informix ODBC driver. Are you able to run something akin to SQL Profiler on the linked server to see what command it's receiving?
I'm not sure what the answer is, but (assuming that your counts of 100 and 120 are accurate) can you not capture the data from the two runs and compare it? That might give you some clues as to what's going on. For example, is it completely different datat, or is it duplicate rows (in the 120 row batch).
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.