Issues with Access 2003 project in using SQL Server 2005 - sql

Our company has a Access 2003 project that runs on a SQL Server 2000 database. We installed SQL Server 2005 on a new box and migrated the database from SQL 2000 to SQL 2005. The Access 2003 project is now pointing to the new database. After the upgrade the Access 2003 project fails when trying to execute a stored procedure. Upon investigation an error message is presented saying that the stored procedure does not exist. When I view the available stored procedures the names appear but with a ;1 a the end.
Is this an issue of incompatibility between Access 2003 and SQL Server 2005 or could I have done something incorrectly during the migration?
I saw another post which mentioned upgrading to Access 2007. Is this a possible solution?

The postfix number is an arcane feature of SQL Server going back years - it allows you to create multiple procedures with the same name (yeah, like that's not going to confuse anyone ever).
It's deprecated so it's hardly ever seen but whatever process your migration did seems to have caused it.

Related

Cannot find sequences in Microsoft SQL Server Management Studio 19

I have tried creating a sequence for my table in Microsoft SQL Server Management Studio 18. I have a syntax error for some reason (although I have checked multiple times the syntax), but I cannot even find the sequences folder for my database. I have also tried not writing the schema name, but the same error appears. What might be the problem? Where do I go wrong?
Here is a screenshot of the problem
First note that SSMS (SQL Server Management Studio) is just a client application that talks to a connected SQL Server instance in the background. So SSMS only passes your SQL statements to the connected SQL Server and shows you the results that SQL Server returns. Nothing more.
What is the version of the SQL Server instance to which your SSMS is connected? (You can check it quickly by executing the SQL statement PRINT ##VERSION.)
You should be aware that the CREATE SEQUENCE statement is only supported by SQL Server 2012 and higher.

Moving Access 2016 application's data from Access to SQL Server 2016

I have a seemingly straight forward project, which unexpectedly faces many obstacles.
I need to move backend data of the existing Access 2016 application from Access to SQL Server 2016.
The challenges I face are:
The simplest and recommended way to migrate Access to SQL Server is using Microsoft SQL Server Assistant (SSMA) for Access. The problem is that my Access is 32-bit Click-to-Run edition. Because the target is SQL Server 2016, I should use SSMA for Access v.7.6.0, which is available only in 64-bit. To use it, I need to install 64-bit Access Runtime, which could not be installed, because per the error message “Windows Installer and Click-to-Run editions of Office programs don't get along”. The earlier version of SSMA for Access 6.0 comes in 32-bit and connects to Access fine, but could not connect to SQL Server 2016, as 2014 is the latest version it supports. Ignoring the warning and forcing the connection to SQL Server 2016 causes error collecting data… Thus, I could not use SSMA.
I was able to migrate the data from Access to SQL Server using SSIS. Now, my challenge is to repoint existing Access tables to their SQL Server copies. I was trying link, but it appears that existing Access tables could be linked only to the file system data source. If I try to make link from the SQL Server side, I could only create new linked tables, which do not do me much good as I am trying to avoid massive changes in the application. Could it be that I am missing something simple here?..
Some Access tables have columns of attachment data type. SSIS doesn’t handle attachment data type correctly. To the best of my knowledge, neither does SSMA. So, when I get to link Access tables to SQL Server, I would probably need to write some code to move attachments from the backup Access database to SQL Server. Is there some other an easier solution?
Any suggestions are greatly appreciated.
That is correct. It is a mess. You can use another (virtual) machine with a clean 64-bit Access install.
Delete the current tables in the frontend and link the SQL Server tables. They may be given a "dbo_" prefix which you can remove by renaming the tables.
This is a rewrite. Attachment fields are not supported in SQL Server. Neither are other fancy features like lookup fields and multivalue fields.

SQL Database Project References to on-the-fly Temp Tables

I am trying to take a legacy database that is now on SQL Server 2008 R2 and create a database project within Visual Studio 2010 for it. There are several stored procedures that used some "on-the-fly" temp tables (the kind where you SELECT * INTO #NewTempTable) Obviously this causes some SQL04151 reference warnings in the database project.
Is there any way to fix or just maybe ignore these specific warnings? I know the immediate answer might be to actually declare the temp table within the procedure and define the columns, but at this point, that isn't an option.
This does not appear to be an issue with the latest database project type for VS 2010, installed as part of SQL Server Data Tools.
Try to install SQL Server Data Tools. After it's installed you'll be able to upgrade your database project to the new type by right-clicking it in Solution Explorer. (The new project type is backwards compatible with SQL 2008 and SQL 2005 and also comes with some significant improvements.)
FYI the new project type has a very generic name of "SQL Server Database Project" and you'll find it in the "SQL Server" template group as opposed to the "Database > SQL Server" group.
Turn SET FMTONLY OFF in your stored procedures.
From MSDN:
Returns only metadata to the client. Can be used to test the format of
the response without actually running the query.
Your issue is that by default Visual Studio has this setting turned on... which allows it to determine the format of the response without running the query, but this doesn't work if temp tables are used.
Here's a discussion of this issue on MS Connect: Improve FMTONLY Intelligence
Per Microsoft's response, this is fixed in 2012, but won't be addressed in earlier versions.
Lastly, here's a related discussion on the FMTONLY issue.

SQL Server 2008 Web edition

My company is planning to migrate it's intranet/internet based ERP to the latest form of MS SQL Database available.
Presently we are using SQL Server 2000 Professional.
And we are planning to shift to SQL Server 2008 Web edition.
Please tell me whether this is the right step and whether it is feasible or not.
Thank you in advance.
"Please tell me whether this is the right step " - that's something you and your company need to decide.
It is feasible, and in the majority of cases straight forward.
Your first step should be to run the Microsoft SQL Server 2008 Upgrade Advisor
Microsoft SQL Server 2008 R2 Feature Pack contains the Microsoft SQL Server 2008 R2 Upgrade Advisor
Formulate and test a rollback plan
Determine your upgrade window and acceptable downtime.
Ensure database consistency: Run DBCC CHECKDB on databases to be upgraded to ensure that they are in a consistent state before performing the upgrade.
Back up all important files: Back up all SQL Server databases from the instance to be upgraded (including master, model and msdb), data and transaction log files, as well as any application files, script files, extract files, etc. so that you can completely restore them in the event of a failure.
It's both feasible and easy. The path from one version of SQL Server to another is usually pretty simple. Do you have any special stored procedures or reports generated in SQL Server that need to be rewritten/re-imported?
As far as right step - the question is, Why? If it's working, do you really need to mess with it?
If it's for intranet (some app for your internal usage) then consider using SQL 2008 Express edition. It's free and you can use it as an instance running along the full 2000 version. That way you will have some extra features from the full version.
But you have to know that applications running on SQL 2000 may not work on 2008 and they are even more probable not to work on 2008 R2.

Migrating Access Tables to SQL Server - Beginner

I'm working in an Access 2007 database and need help migrating tables to SQL server. Is this possible to do having only purchased Access 2007 or do I need to download a separate program for SQL? When I try to create a new SQL database or open an existing one through Access, I'm getting a "CREATE DATABASE" or "CREATE TABLE" error and not sure what the issue is. Any advice would be greatly appreciated!
Take a look at the microsoft's SQL Server Migration Assistant 2005 for Access (v4.0) which supports access 97 - 2007
Yes, you need to install it. There is a free edition of SQL Server, called Sql server express. Database size limit is 4gb. If it suits you go for it. Also, i belive Access has migration tool built in.
Update: In Access 2007 - Database Tools -> Move Data -> Sql Server ( follow the wizard ).