Searched the net in and out and could not find proper info on that, we have a legacy setup that uses Delphi 7 and BDE to connect to SQL Server 2005.
Now we are planning to migrate to SQL Server 2012, what are the chances that it might work or not?
If you are using the SQL Links MSSQL driver then targeting SQL Server 2012 will not be possible. The only way that I have been able to use SQL Links with anything newer than SQL Server 2000 is to keep the database compatibility level set to "SQL Server 2000 (80)". This is not possible in SQL Server 2012. The oldest compatibility level available in this version is "SQL Server 2005 (90)".
SQL Links will send invalid SQL to the server, such as the "*=" syntax for an outer join. Databases set for SQL Server 2005 and above will not accept this syntax.
We've been using Delphi 7 with SQL Server 2012 without significant issue via the Delphi 7 ADO data control components (e.g. TAdoQuery, TAdoCommand). Stored procedures also work fine, and functions can be called via ADO commands objects (TAdoCommand).
We use the SQL Server Native Client 11.0 ODBC driver that comes with SQL Server 2012. Delphi just treats it as another ODBC data interface. Superficially it looks a lot like using MS Access with Delphi 7 (via ADO components and Access OLE driver). No issue with any of the Service Pack(s?) for SQL Server 2012 either. (Sorry, I don't remember exactly what SP's are released for 2012, but we've had no differences w/ or w/o these SP's, and we tested for it).
Most of the development was done on Windows 7 64-bit OS's, and executed on same as well as Windows Server 2008 and 2008R2, both 64-bit. No special settings were required to execute Delphi-compiled executables (which are all 32-bit, obviously).
If you use ODBC "aliases", be sure to use the 32-bit ODBC DSNs, not the 64-bit ODBC DSNs. The 64-bit ODBC Administrator is the one in the Control Panel\Administrative Tools for 64-bit Windows - don't use it here. Use the 32-bit ODBC Administrator, in Windows' SysWOW64: C:\Windows\SysWOW64\odbcad32.exe. The 64-bit ODBC DSNs live in a separate space from the 32-bit DSNs. Delphi 7 is a 32-bit application and won't have access to the 64-bit DSNs (different API I'm guessing).
We may also have had an issue with comments in SQL statements. I think the line comments ("--") didn't work, but multi-line comments worked ("/.../").
Note that while the BDE is preserved by Corel (distributed to this day as the Paradox Runtime; the engine is frozen, however, and does have some issues in modern Windows OS's), it's not needed to access SQL Server data. We use the ODBC aliases directly through the Windows ODBC API (we wrote wrappers in Delphi to make this trivial). However, you can still use the BDE as an interface to these ODBC DSN aliases. If you don't use aliases at all (and don't include any references to DbTables.pas in the source code) you shouldn't need the BDE at all. DbTables.pas initialises the BDE always when it initialises the global Sessions variable in its INTIALIZATION block. You can see this in the bottom of the DbTables.pas source code unit. Without this unit, the BDE isn't initialised or used. (Which also means you cannot use TTable or TQuery components, but those are only for Paradox data; the ADO components like TAdoTable (don't use it unless you want to load the entire data table into memory!), TAdoQuery or TAdoCommand are entirely independent.
Another trick is to use MS Access databases and linked tables to interface between SQL Server and Paradox data tables, if you still need to use BDE-native (i.e. Paradox) tables. But sometimes Access and the BDE don't play well together.
The migration is long done, I'm sure, but in case others are searching for the same answer. Legacy software has a habit of living on...
We've had success using BDE with SQL Server 2008R2. No special config.
Edit: I'm also having initial success on SQL Server 2014 today. Limited testing, but so far so good!
Greg
Related
During our development cycle we create migration-scripts that will be executed on multiple Microsoft SQL Server instances (on different servers).
Since these servers are being maintained by multiple third parties, we can't guarantee that all of them are using the latest Microsoft SQL Server version. For example, some of them are still stuck on 2008 R2.
Unfortunatly, this means that our SQL scripts must at least be compatible with 2008 R2 (and higher).
We would like to add an extra step to our build process (currently driven by MSbuild), which should check if all scripts are compatible with all versions of SQL Server that we should support (2008 R2 and higher). Both in terms of their syntax, but also in terms of built in functions (as an example, the CONCAT-function was only added in 2012).
However, we want to avoid having to install each supported SQL Server version and instead use only SQL Server 2017.
Note:
I've had a look at compatibility modes in SQL Server, but when I set the compatibility level to 100, I seem to still be able to use SQL Server 2012 features like the CONCAT-function. Which doesn't surprise me, as I expect this to be intended for backward compatibility, rather than blocking features.
These similar questions didn't really help either: Using SQL Server Express 2008 with SQL Server 2005 database -how to check for compatibility, How to check sql script compatibility agains SQL 2008
Are there any other options?
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.
After seeing a lot of things in the internet I haven't found any explanation between the two file types: .mdf and .sdf.
.sdf would be a compact version of SQL Server (.mdf) I believe. Still they appear utterly different.
Have followed the two tutorials on msdn, i.e. MVC Movie App and the Musicstore. Both use .sdf.
Partial quote (full): 'First of all it should be "|DataDirectory|ASPNETDBContext.mdf" (notice the extension difference). Your applic...'
Both tutorials have the connection string to .sdf, i.e.:
<add name ="MovieDBContext"
connectionString ="Data Source=|DataDirectory|Movies.sdf"
providerName ="System.Data.SqlServerCe.4.0"
/>
<add name ="MusicStoreEntities"
connectionString ="Data Source=|DataDirectory|MvcMusicStore.sdf"
providerName ="System.Data.SqlServerCe.4.0"
/>
Question:
My question is what to use where and when? More over why to use which where.
SQL Server Compact (sdf files) popular in Windows phone for storing some data (small count of data), also it could be used in web sites, but it has poor performance, even SQLite is better.
SQL Server (mdf files) used in big sites with a lot of data. Its more powerful, but cant be used in phones and must be installed on servers.
Look this: Comparison of SQL Server Compact, SQL Server Express 2012 and LocalDB
SQL Server Compact Edition is indeed quite different from "regular" SQL Server.
SQL Server CE is a stand-alone, one-user database that gets loaded by your application on the machine where your code runs; it has all data in the one single .sdf file and support only a small subset of the "regular" SQL Server (and its features). SQL Server CE is great for simple, stand-alone, one-user apps (like phone apps).
"Real" SQL Server is a server product - you install it on a server, your clients only connect to it (typically, the client machines don't have SQL Server itself installed). It's a full-blown RDBMS with everything - stored proc, triggers etc. and thus best optimized to handle structured, large-scale data - think enterprise applications, such as order handling, invoicing, accounting, large-scale databases for multiple users of any kind.
First, the sql server database file is not a full sql server database, if you're creating it in this fashion it's a sql server express. Sql Server Express databases aren't terribly fantastic to use since most hosts don't run sql server express and publishing them is tricky if you then try to get them running on a sql server database. Better to start with sql server first then express and migrate.
the local db is actually sql server compact edition. http://en.wikipedia.org/wiki/SQL_Server_Compact
For connection strings, go to http://www.connectionstrings.com/sql-server/ There is pretty much every connection string available there. To work with SQL Server Express you will need to have it installed, and to manage it you will need to download the sql server express management tools. Generally, most sql express instances are designed to be used with local accounts but if I remember correctly you can use the management tools to create a sql server login.
A client wants to host their MS Access 2003 backend database into SQL Server 2008 that resides in a different server. They will be using upsizing wizard to move their databases and tables into SQL server.
A client also has MS Access front end application written in VB. After upsizing their database tables to SQL, they want to use SQL server to read/write data and also use adv. programmability features of SQL Server like stored Procs, functions etc. My team will host their SQL database.
Client will have a growing # of users entering data. So what would be the best option for our team to provide access to our SQL server so that they can use only their databases in our SQL Server?Is there a way to provide them a connection string or something like that so that they could test it in their front end application to see if they could connect to our SQL Server to read/write?Basically I want to know What are the different avenues to connect MS Access 2003 front end application written in VB to connect to SQL Server database hosted in a different server so that a user could read/write to SQL database tables? Any thoughts? Thanks.
Actually, how this setup works is not any different than if your developers were using c++, vb.net, c# or even asp.net. At the end of the day these software development tools such as c++, or FoxPro or MS Access are simply tools that let you write software. The ability of Access to connect to MySql or Oracle or insert your favorite X database brand has existed from day one.
As long as your database supports what is called "open database connectivity" then you are off to the races. And how you setup that database server to allow some software written in say c# or FoxPro or MS Access will not really change much of anything to my knowledge.
So Access is just like any other software tool such as c++ or vb.net – it is a tool that lets you write code and you connect that application and user interface to some database system you choose.
The connection technology that Access uses here is based on industry standards and thus your setup and maintains of the server side will quite much be the same for any other application(s) that you have running on premises that utilize SQL server now.
About the only relevant issue here is that in Access you have a choice of two data object models, ADO and DAO. Right now, since Microsoft is depreciating ADO and they are continuing investment in DAO and also recommending to use open database connectivity. For example, Access 2010 ships with support baked in for SQL Azure (cloud sql), and that support is based on open database connectivity.
So at this point time as it did back in 2003 the recommend data object model in Access is to use DAO.
You can read about the depreciation of ADO support in SQL server here:
http://blogs.msdn.com/b/sqlnativeclient/archive/2011/08/29/microsoft-is-aligning-with-odbc-for-native-relational-data-access.aspx
While a for good number of general exports and imports and that of linking to SQL server can occur 100% inside of Access, those users will STILL need a set of client tools beyond Access to effectively work with SQL server if over time they going to start using SQL server features. This thus suggests they will need some edition of SSMS (Sql server management studio). The free express version of SSMS should more than suffice in this case.
I am a junior developer and about to get my feet wet in my first "real" project. However we are trying to figure out a way to set everything up as the current developer lives out of country.
I was told to install certain programs, subversion clients and SQL Server 2000.
It does not seem that SQL Server 2000 can be installed on Windows 7. Are there inherent issues with me developing in a higher version of SQL Server like 2005? Is there an issue with stored procedures that can not be properly translated from on SQL Server version to another?
Again, I'm fairly new at this; please let me know if this is just a bad idea, impossible and any other guidance you can provide.
There are many features in newer versions of MSSQL that were not there in 2000 (multi-row inserts, newer hashing algorithms, and VARCHAR(MAX) to name a few). If you're using SQL Server Management Studio, it will not check these differences for you, even if you are connected to a SQL server 2000 database - it automatically uses 2008 rules for its syntax highlighting. Because of this it's easy to accidentally write code that's not 2000-compatible.
As far as getting 2000 running, if you have the install disk for an older version of windows, you could run a VM (http://www.microsoft.com/windows/virtual-pc/) and install the database server there. If your company has a separate development environment, you could create a copy of the production database to work off of as well.
The newer versions of SQL server bring new language and database features, if you write something using a feature that is available in SQL 2005 and not 2000 i.e. PIVOT then when you try and promote this to live then it will just get a syntax error.
There is no translation, if you went back in time 11 years, you'd still speak English you'd just get an odd look if you talked about 'Tweeting'.
You can set the database compatibility level to an earlier version for the specific database you are working on. This will stop you using the more modern features.
For the most part, you won't run into issues is you're simply running standard stored procedures and SQL statements.
However, there are several things that might not work properly if you're not in sync. SQL2005 was a relatively major upgrade and instroduced quite a bit of new functionality.
I don't know what you've got for available resources - dollars, etc, but if you have an MSDN Subscription at a level that provides you access to operating systems, then I would strongly recommend setting up a virual machine with an older version of Windows using your MSDN licenses, just to keep things on an even playing field.