I have a SQL Server 2012 database with an Access 2007 front-end. My problem is that Access does not recognise SQL Server's dates as they are in a different format.
SQL Server-s format is YYYY-MM-DD
Access' format is DD-MM-YYYY
When the date is displayed in a text-box, it is displayed as a string (without the little calendar icon next to it).
Is there anyway I can configure my Access front-end so that it recognises SQL Server's dates?
I used Microsoft SQL Server Migration Assistant for Access to migrate the data into SQL Server
As this DB is in development I have the SQL Server on my local machine in C drive (no virtual drives)
From my research I have found this answer:
The problem the user has encountered is with a Driver. Microsoft has a new DLL that must be put on a client
workstation (or server in the case of Citrix). Once that is done, all the dates in MS Access will work
properly. My lastest experience with Access 2010 was exactly the same as Access 2003.
It required a DLL. From there, investigate using a DNS-Less connection string
Where would I find this DDL driver and how would I install it.
Thanks
Maggs
I found that SSMA for some reason converted all the datetimes to datetime2. I went into SQL Server Management Studio and changed them to datetimes and it fixed the issue. You could also check the field mapping in SSMA and adjust it before migrating.
(I have the exact same environment - SQL Server 2012 and Access 2007, using SSMA.)
I am using SQL Server 2012 on my local PC (Vista) and have an Access 2010 frontend with ~75 linked tables.
The table in SQL Server has a column named 'EnteredDate' that is defined as 'datetime'.
In Access the 'EnteredDate'column is defined as 'Date/Time'.
In Access, I just ran the following query with proper results:
SELECT DataError.Description, DataError.EnteredDate
FROM DataError
WHERE (((DataError.EnteredDate) Between #1/1/2010# And #1/31/2010#));
Related
I am attempting to migrate a number of stored procedures, which insert to Microsoft Access 2002-2003 format database files, as linked servers.
The process is currently working fine on the following configuration
Windows Server 2008 R2 Standard
SQL Server 2014
Microsoft Access Database Engine 2010 x64 - v14.0.7015.1000
The updated configuration is as follows
Windows Server 2019 Datacenter
SQL Server 2019
Microsoft Access Database Engine 2010 x64 - v14.0.7015.1000
The Microsoft.ACE.OLEDB.12.0 has registered fine on the newer server configuration, and is available as a linked server "provider"
The SP inserts to a number of tables, with varying data types, and all are successful, with the exception of fields where the SQL Server field is of type nvarchar and the Access mdb field is of type "Long Text", where I get the error.
Msg 7344, Level 16, State 1, Line 182
The OLE DB provider "Microsoft.ACE.OLEDB.12.0" for linked server "[Access mdb Linked Server Name]" could not INSERT INTO table "[Access mdb as Linked Server]...[Table Name]" because of column "[Column Name]". The column had a bad status.
The Long text fields in the Access mdb are reported/displayed as varchar data type, in the linked server configuration.
I have tried writing simple, short, strings to the field, CASTing as varchar data type, but still get the same error.
I've done lots of googling, but can find no examples of others experiencing similar issues.
I suspect it is a compatibility issue, between the SQL server version and access database engine but, again, have been unable to find any useful resource.
Has anyone experienced a similar issue, and found a resolution?
Or if you can direct me to a suitable resource where I can find more info.
I managed to resolve this, with changes to the configuration of the OLEDB provider on the SQL server.
It was necessary to enable both:
Dynamic Parameter
and
Allow inprocess
in the provider Options
To monitor SQL Server jobs in a VBA app, I run the sp_get_composite_job_info stored procedure from the msdb database using ADO. I check the current_execution_step field once I have the results in a ADODB.Recordset. This has worked fine with SQL Server 2012 for years.
We just migrated to SQL Server 2019 and now the same code which still works on SQL Server 2012 is returning an unreadable value for the current_execution_step field.
Instead of "4 (Step Name)", I get a bunch of rectangles and squares.
If I run the same call to sp_get_composite_job_info in SSMS, I can read the current_execution_step field just fine on both servers. It's only when I try to read that field in VBA/ADO that it's gibberish.
What's worse, I can read other fields from that same recordset just fine. It's only this one field (which just happens to be the only field I need to read) that is unreadable.
The driver I'm using in VBA is ODBC Driver 17 for SQL Server. But again, I use the same driver for both servers, and only 2019 has this issue.
What could be causing this?
The SQL Server 2012 version of sp_get_composite_job_info (undocumented as #RBarryYoung mentioned) returns current_execution_step as nvarchar(128) whereas SQL Server 2019 returns nvarchar(MAX).
ADO is unaware of SQL Server datatypes introduced after SQL Server 2000. Try installing the latest MSOLEDBSQL OLE DB driver (ADO is natively OLE DB) and specifying the DataTypeCompatibility=80 in the connection string.
Fortunately, the answer was as simple as going back to OLE and switching the Provider to SQLNCLI11 instead of SQLOLEDB. Since SQLNCLI11 is omnipresent, I don't have to hunt down all of the machines that might use these apps and install MSOLEDBSQL on them.
Our tool uses SQL Server 2012 LocalDB to store data. This as installed by the MSI, not full express. Users recently moved to new machines using other applications that connect via SQL Server 2019.
My understanding is that installing SQL Server LocalDB on top of an installation of SQL Server 2019 shouldn't cause an issue, being as how SQL Server Express installs as a named instance by default.
My concern when I look at connection strings, however, is that mine doesn't identify the server instance quite in the way I've seen recommended, only the Data Source:
Data Source=(localdb)\v11.0;Integrated Security=True;AttachDbFileName=C:\Database\Database.mdf;Connection Timeout=10000
This does connect, in case there's doubt. But referencing connectionStrings.com, I see recommended this:
Server=(localdb)\v11.0;Integrated Security=true;AttachDbFileName=C:\MyFolder\MyData.mdf;
In my mind, Data Source=(localdb)\v11.0 is already a clear designation of the instance, but I'm unsure what happens when SQL Server Express installs after SQL Server.
What should I look out for? Do I need to replace Data Source with Server? Will I need to change any part of (localdb)\v11.0 to account for the order SQL Server Express has been installed in compared with SQL Server?
EDIT 1
Updating the connection string by replacing 'Data Source' with 'Server' works. The question still remains, how will LocalDBs installing second affect what follows Server=?
I am trying to install SQL Server 2014. In the setup, I have clicked on Default instance (rather than Named instance) and want to make the Instance ID empty. My main goal is to be able to connect to SQL Server using just .\. But I am being forced to input an Instance ID even though I am pretty sure I shouldn't need to put one in if there are no other instances installed (which there are not). I am using this guide here and am at step 14 which shows screenshots of what I am seeing:
http://www.exactsoftware.com/docs/DocView.aspx?DocumentID=%7Ba6937c87-21f5-46db-a166-ba84e83037e3%7D
Now it could be that I have misunderstood, and Instance ID is always required, but if not, do you know why I am forced to put one in?
Please note, that it automatically sets an InstanceID of MSSQLSERVER.
Also, I currently have the following things installed:
Microsoft SQL Server 2014 Transact-SQL Compiler Service
Microsoft SQL Server 2014 Transact-SQL Compiler ScriptDom
Microsoft SQL Server 2014 T-SQL Language Service
Microsoft SQL Server Compact 4.0 SP1 x64 ENU
Microsoft SQL Server Data Tools - enu (14.0.50616.0)
Microsoft SQL Server System CLR Types
Do I maybe need to uninstall any of these?
Even a default instance has a name, in this case MSSQLSERVER.
This is because the directory structure of the SQL-Server installation, the registry entries and service names reflect the name of the instance. For a default instance there is no need to specify the name of the instance to make a connection.
https://msdn.microsoft.com/en-us/library/ms143531.aspx
Has anyone here moved the database underlying a SP 2010 install from one database instance to another (same data, just hosted in another instance)?
For example. we just want to move the database to a diffrerent machine.
In addition, has anyone moved SP 2010 from using SQL Express to a higher version of SQL Server? I would like to run some proof of concept tests with SQL Express, and if all goes well, then move to SQL Standard or Enterprise.
Cheers,
Daniel
Check out the following article:
http://technet.microsoft.com/en-us/library/cc512725.aspx
I don't think you'll run into any problems, just make sure you aren't going backwards in versions between databases. Backing up a database in SQL Server 2008 and restoring in 2005 isn't easy.
I've never done this with SharePoint, but I believe it lets you specify the location of the configuration database. Then you just need to match the user permissions.
The TechNet article "Move All Databases (SharePoint 2010)" is your main guide.
Note that this article contains the following warning:
The new database server must be running the same version of Windows
Server and Microsoft SQL Server as the existing database server.
This in NOT true!
Both from my own experience in migrating SharePoint databases and talks I've had with Microsoft Primary Field Engineering, I can say this method also works when SQL Server versions differ. But only if you upgrade to higher SQL Server versions (i.e. SQL Server 2005 to SQL Server 2008 R2). I was told this scenario is also fully supported by Microsoft.
Also, don't forget to update the database compatibility level for the migrated databases. This should future-proof your databases and enable advanced SQL Server optimization.