I have a .GDB database (old one) and the data in it is very important
I need to convert that .gdb database to a SQL Server database - can anyone help me...
Create connections to both source GDB and Destination SQL Server in ArcCatalog. Copy everything from source and paste it into the destination. You won't be able to do it with SQL tools alone.
Lacking ESRI software, for simple cases, my workflow is to use the GDAL C++ API to read the GDB. This requires the GDAL File GDB driver. Then I will use Microsoft.SqlServer.Types to transfer to SQL Server. This involves low-level APIs and you need to understand the spatial types in the respective libraries. It gets complex if you have polygons with rings, for example.
I'm not aware of a tool that will automatically convert between these database types. You'll need to use an application that can read the old database type (Firebase), learn the table design, create a similar table design in SQL Server, and use the application to load the data from Firebase to SQL Server.
Typically, this kind of work is called ETL (Extract/Transform/Load) and is done with migration tools like SQL Server Integration Service (SSIS). SSIS is free with SQL Server, and there are a lot of books available on how to use it - but like learning to develop software, this isn't a small task.
The easiest way to export Esri File Geodatabase FGDB (.gdb) data to MS SQL Server is with ArcGIS for Desktop at the Standard or Advanced level.
You may also want to try exporting to shapefile (SHP) format (an open transitional format) then import to your MS SQL Server. I've seen a tool online that has worked for me called Shape2SQL.
Esri also has an open File Geodatabase API that you can use to write your own too.
I highly recommend FME Workbench for GIS data conversion. It's like SQL Server Integration Services (ETL) but for GIS. Graphical interface, connect data readers with data writes, insert transforms, run them, etc.
Related
suppose I have a custom CRM software, writing data to MS-SQL-SERVER 2005, and I am trying to pull data from MS-SQL-SERVER to MS-Project-client 2010. I did some reading and have this questions:
what is the "best" way to pull data from sql-server to Ms-Project-CLIENT 2010? Can I do that "directly" without Ms-Project-SERVER?
how about push it back to SQL-server from ms-project-client 2010? I read somewhere using the xml structure in ms-project and it is not recommended...
Do I have to use VBA (in Ms Project client 2010) or VB 2010? (I have only those options: VB/VBA)
Sorry if it looks like amateurs, but I really need help.
Suppose your application write to it's own database and it doesn't write to MS Project Server database(s).
If the assumption is correct than you definitely shouldn't care about MS Project Server. You practically have two options how to write to the database and your choice depends on things like: do you want to distribute login and password for the database to all users.
You can either write "directly" to the database using OLE DB or ADO either from .NET Add-On for MS Project or from VBA macro. Or you can create intermediate server and send your data to the server and that server will interact with the database.
But if your application writes to MS Project Server database and the server's version is 2007+ - I would highly recommend to do that either through Project Server Interface (PSI) or through MS Project Automation. When MS Project writes to database it does lot of magic and it would be better to let it does it's job or you have a great chance to corrupt the database in some way and recovery will be painful and/or expensive.
I'm looking for the best approach (or a couple of good ones to choose from) for extracting from a Progress database (v10.2b). The eventual target will be SQL Server (v2008). I say "eventual target", because I don't necessarily have to connect directly to Progress from within SQL Server, i.e. I'm not averse to extracting from Progress to a text file, and then importing that into SQL Server.
My research on approaches came up with scenarios that don't match mine;
Migrating an entire Progress DB to SQL Server
Exporting entire tables from Progress to SQL Server
Using Progress-specific tools, something to which I do not have access
I am able to connect to Progress using ODBC, and have written some queries from within Visual Studio (v2010). I've also done a bit of custom programming against the Progress database, building a simple web interface to prove out a few things.
So, my requirement is to use ODBC, and build a routine that runs a specific query on a daily basis daily. The results of this query will then be imported into a SQL Server database. Thanks in advance for your help.
Update
After some additional research, I did find that a Linked Server is what I'm looking for. Some notes for others working with SQL Server Express;
If it's SQL Server Express that you are working with, you may not see a program on your desktop or in the Start Menu for DTS. I found DTSWizard.exe nested in my SQL Server Program Files (for me, C:\Program Files (x86)\Microsoft SQL Server\100\DTS\Binn), and was able to simply create a shortcut.
Also, because I'm using the SQL Express version of SQL Server, I wasn't able to save the Package I'd created. So, after creating the Package and running it once, I simply re-ran the package, and saved off my SQL for use in teh future.
Bit of a late answer, but in case anyone else was looking to do this...
You can use linked server, but you will find that the performance won't be as good as directly connecting via the ODBC drivers, also the translation of the data types may mean that you cannot access some tables. The linked server might be handy though for exploring the data.
If you use SSIS with the ODBC drivers (you will have to use ADO.NET data sources) then this will perform the most efficiently, and as well you should get more accurate data types (remember that the data types within progress can change dynamically).
If you have to extract a lot of tables, I would look at BIML to help you achieve this. BIML (Business Intelligence Markup Language) can help you create dynamically many SSIS packages on the fly which can be called from a master package. This master package can then be scheduled or run ad-hoc and so can any of the child packages as needed.
Can you connect to the Progress DB using OLE? If so, you could use SQL Server Linked Server to bypass the need for extracting to a file which would then be loaded into SQL Server. Alternately, you could extract to Excel and then import from Excel to SQL Server.
I have a two-part application, where there is a central database that is edited, and then at certain times, the data is released and distributed as its own application. I would like to use a standalone database for the central database (MySQL, Postgres, Oracle, SQL Server, etc.) and then have a reliable export to an embedded database (probably SQLite) for distribution.
What tools/processes are available for such an export, or is it a practice to be avoided?
EDIT: A couple of additional pieces of information. The distributed application should be able to run without having to connect to another server (ex: your spellchecker still works even you don't have internet), and I don't want to install a full DB server for read-only access to the data.
If you really only want your clients to have read-access to the offline data it should not be that difficult to update your client-data manually.
A good practice would be to use the same product for the server database and the client database. You wouldn't have to write SQL-Statements twice since they use the same SOL-Dialect and same features.
Firebird for example offers a server
and an embedded version.
Also Microsoft offers their MS SQL Server
as a mobile version (compact edition) and there are
also Synchronization services
provided by Microsoft (good blog
describing sync services in visual
studio:
http://keithelder.net/blog/archive/2007/09/23/Sync-Services-for-SQL-Server-Compact-Edition-3.5-in-Visual.aspx)
MySQL has a product which is called "MySQLMobile" but I never actually used it.
I can also recommend SQLite as an embedded database since it is very easy to use.
Depending on your bandwidth and data amount you could even download the whole database and delete the old one. (in Firebird for example only copy the database files and it will also work with the mobile version) Very easy - BUT you have to know if it will work for your scenario. If you have more data you will need something more flexible and sophisticated, only updating the data that really changed.
I have a client that uses a point-of-sale solution involving an Access database for its back-end storage. I am trying to provide this client with a service that involves, for SLA reasons, the need to copy parts of this Access database into tables in my own database server which runs SQL Server 2008. I need to do this on a periodic basis, probably about 5 times a day.
Is there an easy programmatic way to do this, or an available tool? I don't want to handcraft what I assume is a relatively common task.
I am running this on SQL Azure, so there's no way for me to run prepackaged software on the server. It would either have to be open source and portable to Azure or executable on the client's computer.
I'm unfortunately thinking I'm going to have to roll my own tool to do this. Any suggestions or more tools that are out there that can do this themselves before I go ahead?
David, I looked at multiple solution for a similar problem: converting from dbf to mysql, here are 3 solutions (all commercial - but relatively inexpensive) that can work for you:
Full Convert
SQL Manager
ESF
Other than that I couldn't find a good robust data conversion tool that would be open source or free. At least not for DBF to MySQL conversion. There might be something out there for SQL/Access. You could roll out your own solution, but is it worth your time?
DISCLOSURE: I ended up using Full Convert.
Also all of these products generate some sort of batch file, that can be scheduled using Task Manager.
There are two things to consider:
connectivity
ETL tool
For connectivity, you will need to establish VPN tunnel of some sort between the client server and your server.
Then use SSIS to connect to MS Access, to create packages to pull data from MS Access to SQL Server database. On SQL Server, you will need to create new schema, to mirror or be close MS Access
On connectivity side, another option - since MS Access db is in the file, you may be able to FTP the file to your server and point SSIS to the file
I have an Interbase DB. How can I convert it to SQL Server?
You could use SQL Server built in Data Transformation Services (DTS) in SQL Server 2000 or SQL Server Integration Services (SSIS) in SQL Server 2005.
Try setting up an ODBC DSN for Interbase. Then in DTS / SSIS use the Other (ODBC Data Source) and the DSN.
If that does not work then see if Interbase has a utility to export to text files and then use DTS / SSIS to import the text files.
If you want to spend some money, this will do it:
http://www.spectralcore.com/fullconvert/tutorials/convert-interbase-firebird-to-mssql-sql-server.php
The Interbase DB Wikipedia page says that it supports OBDC and ADO.NET, so I would think that SQL Server can probably import this database on its own. I don't have access to an Interbase DB installation to try, but you might find these pages helpful.
MSDN on import data wizard
MSDN on bulk import command (if Interbase DB can dump a text file)
Article on bulk importing from an ADO.NET supporting source
Hopefully somebody will have direct experience with this database and can help. Good luck!
If you only need to convert tables and data, that's rather simple. Just use ODBC driver for InterBase, connect to it and pump the data.
However, if you need business logic as well, you cannot covert it just like that. You can convert regular tables and views without too much problems. Domain info would be lost but you don't need it in MSSQL anyway. The only problem with tables can be array fields, which you need to convert to separate tables, but that isn't too hard either.
The problem is the conversion of triggers and stored procedures, since InterBase uses its own, custom PSQL language. It has some concepts that are different from MSSQL. For example, you have procedures that can return resultsets, and you would need to convert those to MSSQL functions.
In any case, it shouldn't be too hard, since you're going from low to high complexity, but there are no tools to do it automatically.