Following podcast #59, I've been considering moving some images from an MS Access DB into MS SQL Server (it's the only piece I haven't migrate over yet). Right now they are stored as OLE Objects in the MS Access DB.
However, I haven't got a clue what data type they should be stored as on the SQL Server side, or how to get them inserted through the interface (MS Access via ODBC).
I would use the image type, and I would NOT use Access to transfer them. I'd use the Sql Server Import and Export Wizard to do it. To do so, right-click the database you want to import to in Sql Server Management Studio, select Tasks, and then select Import Data.
There is several BLOB-type fields in MS SQL Server for storing binary data - but some of them have size limitations.
If you use SQL 2005 or higher, the best choice is varbinary(MAX). It can store really big data pieces.
Be warned, that keeping pictures in OLE format will cause a lot of problems for you in future. While you're moving on, consider converting your images to usual graphic files (like JPG). It will save resourses of SQL Server and improve Access displaying speed.
I recommend to take a look at AccessImagine (http://access.bukrek.net), it would help you to avoid a lot of headaches about the images. Just look at video.
We have used DBPix from Ammara, www.Ammara.com for 5 or 6 years now to handle the capture and display. Very easy to use ActiveX control with complete sample code in their documentation, and affordable.
Our team preferentially stores images on disk and refers to them by storing their location in a varchar, but the control will handle both methods.
You can try to compare em, it can be interesting as AccessImagine is newer one.
Related
I have a server on Microsoft Server Management Studio that I need to download in order to work on it locally.
When I right click on the database and go to Tasks -- Export Data I get the SQL Server Import Export Wizard. I am able to pick a source, but I can't find the write destination to allow me to download the file locally.
I don't want to transfer the files to another server, I just want to have to local file to work with.
Is this the right approach? Or is there a better way to handle this task?
I don't want to transfer the files to another server....
A SQL Server database is a complex binary structure. To read it / work with it, you need a copy of SQL Server on the machine you want to work with it on. The Developer edition would be a good option for downloading to a local machine, or you could install the free version and export data to a local database.
If what you are trying to do is to just see the data without any of the SQL Server functionality, then you can export them to different types of files through the import/export functionality. However, unless the amount of data involved is quite small, I would really recommend against this. The organization and cross-referencing of data can be quite extensive depending on how the database was designed.
These are about your only two options. What you end up doing may depend on what you are planning to do with the data.
I want to know how to convert an Access database file into a SQL Server (.mdf file) database?
The MS Access "Upsize Wizard" was discontinued with Access 2012. SQL Server Migration Assistant (SSMA) is now recommended. Reference: https://accessexperts.com/blog/2013/01/30/access-2013-is-here-but-wheres-the-sql-server-upsizing-wizard/
However, as Johnny Bones noted, I found it relatively easy to create a new empty SQL Server (2012) database and then import:
SQL Server Management Studio, R-click on the newly created Database | Tasks | Import Data -> SQL Server Import Wizard
I used "Access Database Engine" instead of "Jet Database Engine" for
no reason other than I GUESSED Jet was older. Mine is a throw-away
project you may want to research the difference.
I 'weeded out' the
Access queries (views) and just imported the tables.
So far it looks
like everything was imported OK.
The simple answer is; you can not "convert" an Access database to a SQL database. You can, however, import the Access database (tables only) into SQL. Remember that SQL is a true database, and, as such, contains no front end or GUI creation mechanisms. You will still need Access (or C# or VB or another front-end builder) to create the interface.
You may already know this, but in SQL Server a Query is called a View, and Modules are called Stored Procedures. You will need to convert your Access queries and modules accordingly if you're planning on having that all reside server-side.
It's actually pretty easy to import Access tables into SQL Server, you would just create a database on a server, right-click on the database name and choose Tasks --> Import Data. There you will choose Microsoft Access as your Data Source. The rest should be pretty self-explanatory.
JonnyBones wrote a good full answer. Other have made suggestions for tools which may work. However, the SSMA (SQL Server Migration Assistant) is likely to be the best option now. (See this youtube video for help with understanding some of the issues to overcome and an explaination of how to use SSMA.
Befre you consider using other tools, which may do more, you should find out why to use them instead of SSMA. Check out the youtube video as a starting point.
Be aware that the MS Access Upsizing wizard was great but is now discontinued, and there was a bit of a gap before MS created a decent version of SSMA, which is when&why these other tools came into existence.
SSMA should do what you need.
There are some access things that do not get moved to SQLServer and some that do.
eg Access triggers do not. Access tables constraints do, Access boolean datatypes so - of sorts - but you need to do some work. The video will explain most issues well.
Harvey
You can try with the Upsize Wizard or copy content of the table from SHOW TABLE DATA and paste to the target table with the same structure as the source.
I have two applications with own database.
1.) Desktop application which has vb.net winforms interface, runs in offline enterprise network and stores data in central database [SQL Server]
**All the data entry and other office operations are carried out and stored in central database
2.) Second application has been build on php. it has html pages and runs as website in online environment. It stores all data in mysql database.
**This application is accessed by registered members only and they are facilitied with different reports of the data processed by 1st application.
Now I have to synchronize data between online and offline database servers. I am planning for following:
1.) Write a small program to export all the data of SQL Server [offline server] to a file in CVS format.
2.) Login to admin Section of live server.
3.) Upload the exported cvs file to the server.
4.) Import the data from cvs file to mysql database.
Is the method i am planning good or it can be tunned to perform good. I would also appreciate for other nice ways for data synchronisation other than changing applications.. ie. network application to some other using mysql database
What you are asking for does not actually sound like bidirectional sync (or movement of data both ways from SQL Server to MySQL and from MySQL to SQL Server) which is a good thing as it really simplifies things for you. Although I suspect your method of using CSV's (which I would assume you would use something like BCP to do this) would work, one of the issues is that you are moving ALL of the data every time you run the process and you are basically overwriting the whole MySQL db everytime. This is obviously somewhat inefficient. Not to mention during that time the MySQL db would not be in a usable state.
One alternative (assuming you have SQL Server 2008 or higher) would be to look into using this technique along with Integrated Change Tracking or Integrated Change Capture. This is a capability within SQL Server that allows you to determine data that has changed since a certain point of time. What you could do is create a process that just extracts the changes since the last time you checked to a CSV file and then apply those to MySQL. If you do this, don't forget to also apply the deletes as well.
I don't think there's an off the shelf solution for what you want that you can use without customization - but the MS Sync framework (http://msdn.microsoft.com/en-us/sync/default) sounds close.
You will probably need to write a provider for MySQL to make it go - which may well be less work than writing the whole data synchronization logic from scratch. Voclare is right about the challenges you could face with writing your own synchronization mechanism...
Do look into SQL Server Integration Service as a good alternate.
I've looked around and can't seem to find anything that answers this specific question.
What is the simplest way to move data from an MS SQL Server 2005 DB to a Postgres install (8.x)?
I've looked into several utilities like "Full Convert Enterprise", etc, and they all fail for one reason or another, ranging from strange errors that make it blow up to inserting nulls rather than actual data (wth?).
I'm looking at a DB with all table except for a single view, no stored procs, functions, etc.
At this point I'm about to write a small utility to do it for me, I just can't believe that's necessary. Surely there's something somewhere that can do this? I'm not even too worried about cost, although free is preferable :)
I don't know why nobody has mentioned the simplest and easiest way using robust MS SQL Server Management Studio.
Simply you just need to use the built-in SSIS Import/export feature. You can follow these steps:
Firstly, you need to install the PostgreSQL ODBC Driver for Windows. It's very important to install the correct version in terms of CPU arch (x86/x64).
Inside Management Studio, Right click on your database: Tasks -> Export Data
Choose SQL Server Native Client as the data source.
Choose .Net Framework Data Provider for ODBC as the destination driver.
Set the Connection String to your database in the following form:
Driver={PostgreSQL ODBC Driver(UNICODE)};Server=;Port=;Database=;UID=;PWD=
In the next page, you just need to select which tables you want to export. SQL Server will generate a default mapping and you are free to edit it. Probably you`ll encounter some Type Mismatch problems which take some time to solve. For example, if you have a boolean column in SQL Server you should export it as int4.
Microsoft Docs hosts a detailed description of connecting to PostgreSQL through ODBC.
PS: if you want to see your installed ODBC Driver, you need to check it via ODBC Data Source Administrator.
Take a look at the Software Catalogue. Under Administration/development tools I see DBConvert for MS SQL & PostgreSQL. Probably there are other similar tools listed.
You can use the MS DTS functionality (renamed to SSIS in the latest version I think). One issue with the DTS is that I've been unable to make it do a commit after each row when loading the data into pg. Which is fine if you only have a couple of 100k rows or so, but it's really very slow.
I usually end up writing a small script that dumps the data out of SQLServer in CSV format, and then use COPY WITH CSV on the PostgreSQL side.
Both those only take care of the data though. Taking care of the schema is a bit harder, since datatypes don't necessarily map straight over. But it can easily be scripted together with a static load of the schema. If the schema is simple (just varchar/int datatypes for example), that part can also easily be scripted off the data in INFORMATION_SCHEMA.
Well there are .NET bindings for MS SQL Server 2005 (obviously) and also for PostgreSQL. So it would only take a few lines of code to code up a program that could transfer data safely from one to the other. The view would probably have to be done manually as Postgres doesn't use the same language for views as SQL Server.
This answer is to help summarize current connection string because someone may overlooked the comment.
Current version of ODBC connection string is:
For 32-bit system
Driver={PostgreSQL UNICODE};Server=192.168.1.xxx;Port=5432;Database=yourDBname;Uid=postgres;Pwd=admin;
For 64-bit system
Driver={PostgreSQL UNICODE(x64)};Server=192.168.1.xxx;Port=5432;Database=yourDBname;Uid=postgres;Pwd=admin;
You can check the driver name by typing ODBC in windows search.
And open ODBC Data Source Administrator
This should be simple. I'm trying to import data from Access into SQL Server. I don't have direct access to the SQL Server database - it's on GoDaddy and they only allow web access. So I can't use the Management Studio tools, or other third-party Access upsizing programs that require remote access to the database.
I wrote a query on the Access database and I'm trying to loop through and insert each record into the corresponding SQL Server table. But it keeps erroring out. I'm fairly certain it's because of the HTML and God knows what other weird characters are in one of the Access text fields. I tried using CFQUERYPARAM but that doesn't seem to help either.
Any ideas would be helpful. Thanks.
Try using the GoDaddy SQL backup/restore tool to get a local copy of the database. At that point, use the SQL Server DTS tool to import the data. It's an easy to use, drag-and-drop graphical interface.
What error(s) get(s) thrown? What odd characters are you using? Are you referring to HTML markup, or extended (eg UTF-8) characters?
If possible, turn on Robust Error Reporting.
If the problem is the page timing out, you can either increase the timeout using the Admin, using the cfsetting tag, or rewrite your script to run a certain number of lines, and then forward to itself at the next start point.
You should be able to execute saved DTS packages in MS SQL Server from the application server's command line. Since this is the case, you can use <cfexecute> to issue a request to DTSRUNNUI.EXE. (See example) This is of course assuming you are on a server where the command is available.
It's never advisable to loop through records when a SQL Update can be used.
It's not clear from your question what database interface layer you are using, but it is possible with the right interfaces to insert data from a source outside a database if the interface being used supports both types of databases. This can be done in the FROM clause of your SQL statement by specifying not just the table name, but the connect string for the database. Assuming that your web host has ODBC drivers for Jet data (you're not actually using Access, which is the app development part -- you're only using the Jet database engine), the connect string should be sufficient.
EDIT: If you use the Jet database engine to do this, you should be able to specify the source table something like this (where tblSQLServer is a table in your Jet MDB that is linked via ODBC to your SQL Server):
INSERT INTO tblSQLServer (ID, OtherField )
SELECT ID, OtherField
FROM [c:\MyDBs\Access.mdb].tblSQLServer
The key point is that you are leveraging the Jet db engine here to do all the heavy lifting for you.