I'm reading shapefiles from a file location, reading their metadata and writing them in the database in a SSIS package.
The SSIS packages work on my local machine successfully. I deployed the same SQL job on the server box and when I run the job on the server box (running under a SSIS Executor proxy), it throws me an OLEDB exception:
The Microsoft Jet database engine could not find the object 'tmp5330'.
Make sure the object exists and that you spell its name and the path
name correctly.
Its definitely happening on the script component where I read the shapefile from a file location and process the metadata. I've double checked that the SSIS account has permissions on the file location (the last folder where the files sit) and it definitely has read permissions on it.
Would be great if someone could help.
The problem is in the configuration of the Jet Engine, it looks like the it does not accept the files longer than eight characters:
to fix that: 'rename the file so that it matches the MS-DOS 8.3 file name format. That is, the file name must be no more than eight characters in length, and it must have a correct extension following the period, such as .dbf for a dBASE file.'
See http://support.microsoft.com/kb/209685 for more details.
Related
For the past few days I'm running into an error, which is well known, but I can't understand what I need to do, even after reading so many different solutions. But please let me start with the task.
A predecessor created a business critical SSIS package using SQL Server Data Tools (2005) 4-5 years ago that basically reads a large table in the database and then segregates the data categorically and pumps the data into separate tables in the same database. At the end it reads the data from these segregated/categorised data tables and exports the data into respective Excel files in a Network drive in the same folder. All these tables have different data dictionaries. All these Excel files are 97-2003 format (.xls).
The Production server is SQL 2005 and Windows 2003. and a New Development environment is created with SQL Server 2012 and Windows 2012, where I need to migrate all the databases, SQL Jobs, SSIS packages. Majority of them completed and are running without issue. I left the complex SSIS packages to the last, so I can deliver something to business to test on.
Now my task is to upgrade the package to write into Excel 2007 xlsx files. No changes at the database level. So, I created OLE DB Connections for all the Excel files and the connections appear to work fine when clicked on Test Connection in Connection dialog. All these Excel files sit in the Dev SQL Server in the same folder (\DevServer\p$\SSIS_Jobs\Process_Data) as the SSIS package. I set the Extended Properties = Excel 12.0 XML in Connection manager. But when I run the package in the BIDS, I'm getting
"Failed to acquire connection "Excel07_Con1". Connection may not be configured or you may not have the right permissions on this connection."
The package is set to 32 bit mode and MSOffice installed is 32bit and installed the Microsoft Access Database Engine 2010 (32-bit) drivers. And the Dev Network drive has Full rights to EveryOne to ReadWrite.
Since this is the last step in the process, the whole job is failing because of this. I'm sure gone through lot of responses to similar questions. Any help would be highly appreciated.
Thanks - Madhu
have you checked project properties? It might be the case that the project in BIDS the following property Runas64Bit is set to TRUE.
Thanks for your responses, I've solved the issue by recreating the package from scratch in SSDT2012. Now the package is working. I suspect it could be the Excel drivers.
Thanks for your time again. - Madhu
I have an existing SSIS package on my DB server and I have another server which is the application server which uses this DB server for its operation. This SSIS package, is being used by a job running on the DB server. I would like to add an additional step. That step is just a basic select count(*) query to get count from one table. I implemented that on my test server and gave the output path in the advanced tab as well. And i got the output in a simple text file.
My question now is, How do i send this output file to my application server instead? Because the output path of a T-SQL server seems to only take local drives. I tried giving the path of my application server(which was being used by the SSIS package already) but the output doesn't come on the text file even 'though it says the job executed successfully. I don't see the necessity to create another SSIS package for just getting a simple count info.
Use the UNC path to your application server file system.
So we got an old program, from about 2006-2007.
that program uses a very large database.
the database is separated into 3 files:
(file extensions were renamed.)
1 of 1,061,758,976 bytes
1 of 1,062,225,920 bytes
and 1 of 423,604,224 bytes
(total about 2.4 GB).
what we want to do is get rid of that program and write our own, using the same database.
the only problem is that we don't know anything about those files. Rumors says that those files are access files - but we don't know how to confirm that.
also, the goal is to put this whole database into a mySQL database - which is another challenge.
Summarizing:
Determine database type
Converting to mySQL.
Any help will be much appreciated.
EDIT: File header:
Determine database type
The screenshot cited in the comments to the question indicate that the file is an Access .mdb database file. Access database files contain the following 15-character strings starting at byte offset 4:
Standard Jet DB ...for an .mdb file
Standard ACE DB ...for an .accdb file
Converting to mySQL.
The most straightforward way would be to install the MySQL ODBC driver, create an ODBC DSN to the target MySQL server, then open the .mdb file in Access and export the tables to MySQL via ODBC.
Exporting Access Data to MySQL
edit re: "You do not have the necessary permissions..." error
It appears that the database file was encrypted using the "User-Level Security" feature that Access offered for older .mdb files. If so, then to open the file you will need:
The associated Workgroup Security file (often called "Security.mdw", but may have a different name)
Login credentials (username and password) for a user that was created in that Workgroup file.
If you have both of those prerequisites then you should be able to open the file using something like the following from the command-line:
MSACCESS.EXE "C:\Users\Public\uls\db1.mdb" /WRKGRP "C:\Users\Public\uls\Security.mdw"
Search around to see if you can find the associated .mdw file (possibly renamed). Note that if if you find a file named System.mdw under %SystemRoot% or %APPDATA% it may not be the one you need. (Access creates a default Workgroup file for normal unprotected databases.) The file you are looking for should have a similar 15-character string starting at byte offset 4:
Jet System DB ...for an .mdw file (note that there are two trailing spaces to make 15 characters)
I'd like to install AdventureWorks2008 (I just install SQL Server 2008 R2 Express).
Each time I download the recommended version from CodePlex, all I get is a AdventureWorks2008.mdf file. Not only I cannot attach the file from SQL Server Management Studio, but I cannot copy/paste the file directly into the the database.
I've read in several places that I need to use AdventureWorks2008.msi, but I cannot find where to download it.
I just cannot figure out how to install AdventureWorks2008
Thanks for helping
There isn't an .msi file for adventureworks, even though you'll find it mentioned in outdated documentation and books. You aren't alone in finding this confusing -- it seems the web site, files and steps Microsoft provides for installing these databases changes every time I need to install them.
You need to create the database and attach the .mdf file, which is the "data file" referred to in the instructions. (.mdf = primary data file, .ldf = log file, .ndf = secondary data file)
In order to attach the file, you need to make sure you carefully follow the steps here: http://social.technet.microsoft.com/wiki/contents/articles/3735.sql-server-samples-readme-en-us.aspx#Readme_for_Adventure_Works_Sample_Databases
Instructions for 2008R2:
To install AdventureWorks2008R2 OLTP database
Download the AdventureWorks2008R2 Data File.
From File Download, click Save and browse to a location on your local
server.
From SQL Server Management Studio, execute the following code:
Case-insensitive Database
CREATE DATABASE AdventureWorks2008R2
ON (FILENAME = '{drive}:\{file path}\AdventureWorks2008R2_Data.mdf')
FOR ATTACH_REBUILD_LOG;
As an alternative to step 3, you can attach the database using the SQL
Server Management Studio user interface. For more detailed
information, see Attach a Database (SQL Server Management Studio).
Note: You must remove the log file from the list of files to attach.
This will cause the operation to rebuild the log.
Headache saving tip from Aaron Bertrand:
You should place the mdf file in your normal data folder - SQL Server
will already have the proper permissions. You can get this path using
SELECT TOP (1) physical_name FROM master.sys.database_files;
You can directly paste that file into your database directory. For more information you can refer http://tryingmicrosoft.com/error-while-attaching-a-database-to-sql-server-2008-r2/.
The title is self explanatory. Is there a way of directly doing such kind of importing?
The .BAK files from SQL server are in Microsoft Tape Format (MTF) ref: http://www.fpns.net/willy/msbackup.htm
The bak file will probably contain the LDF and MDF files that SQL server uses to store the database.
You will need to use SQL server to extract these. SQL Server Express is free and will do the job.
So, install SQL Server Express edition, and open the SQL Server Powershell. There execute sqlcmd -S <COMPUTERNAME>\SQLExpress (whilst logged in as administrator)
then issue the following command.
restore filelistonly from disk='c:\temp\mydbName-2009-09-29-v10.bak';
GO
This will list the contents of the backup - what you need is the first fields that tell you the logical names - one will be the actual database and the other the log file.
RESTORE DATABASE mydbName FROM disk='c:\temp\mydbName-2009-09-29-v10.bak'
WITH
MOVE 'mydbName' TO 'c:\temp\mydbName_data.mdf',
MOVE 'mydbName_log' TO 'c:\temp\mydbName_data.ldf';
GO
At this point you have extracted the database - then install Microsoft's "Sql Web Data Administrator". together with this export tool and you will have an SQL script that contains the database.
MySql have an application to import db from microsoft sql.
Steps:
Open MySql Workbench
Click on "Database Migration" (if it do not appear you have to install it from MySql update)
Follow the Migration Task List using the simple Wizard.
I did not manage to find a way to do it directly.
Instead I imported the bak file into SQL Server 2008 Express, and then used MySQL Migration Toolkit.
Worked like a charm!
In this problem, the answer is not updated in a timely. So it's happy to say that in 2020 Migrating to MsSQL into MySQL is that much easy. An online converter like RebaseData will do your job with one click. You can just upload your .bak file which is from MsSQL and convert it into .sql format which is readable to MySQL.
Additional note: This can not only convert your .bak files but also this site is for all types of Database migrations that you want.
Although my MySQL background is limited, I don't think you have much luck doing that. However, you should be able to migrate over all of your data by restoring the db to a MSSQL server, then creating a SSIS or DTS package to send your tables and data to the MySQL server.
hope this helps
I highly doubt it. You might want to use DTS/SSIS to do this as Levi says. One think that you might want to do is start the process without actually importing the data. Just do enough to get the basic table structures together. Then you are going to want to change around the resulting table structure, because whatever structure tat will likely be created will be shaky at best.
You might also have to take this a step further and create a staging area that takes in all the data first n a string (varchar) form. Then you can create a script that does validation and conversion to get it into the "real" database, because the two databases don't always work well together, especially when dealing with dates.
The method I used included part of Richard Harrison's method:
So, install SQL Server 2008 Express
edition,
This requires the download of the Web Platform Installer "wpilauncher_n.exe"
Once you have this installed click on the database selection ( you are also required to download Frameworks and Runtimes)
After instalation go to the windows command prompt and:
use sqlcmd -S \SQLExpress (whilst
logged in as administrator)
then issue the following command.
restore filelistonly from
disk='c:\temp\mydbName-2009-09-29-v10.bak';
GO This will list the contents of the
backup - what you need is the first
fields that tell you the logical names
- one will be the actual database and the other the log file.
RESTORE DATABASE mydbName FROM
disk='c:\temp\mydbName-2009-09-29-v10.bak' WITH MOVE 'mydbName' TO
'c:\temp\mydbName_data.mdf', MOVE
'mydbName_log' TO
'c:\temp\mydbName_data.ldf'; GO
I fired up Web Platform Installer and from the what's new tab I installed SQL Server Management Studio and browsed the db to make sure the data was there...
At that point i tried the tool included with MSSQL "SQL Import and Export Wizard" but the result of the csv dump only included the column names...
So instead I just exported results of queries like "select * from users" from the SQL Server Management Studio
SQL Server databases are very Microsoft proprietary. Two options I can think of are:
Dump the database in CSV, XML or similar format that you'd then load into MySQL.
Setup ODBC connection to MySQL and then using DTS transport the data. As Charles Graham has suggested, you may need to build the tables before doing this. But that's as easy as a cut and paste from SQL Enterprise Manager windows to the corresponding MySQL window.
For those attempting Richard's solution above, here are some additional information that might help navigate common errors:
1) When running restore filelistonly you may get Operating system error 5(Access is denied). If that's the case, open SQL Server Configuration Manager and change the login for SQLEXPRESS to a user that has local write privileges.
2) #"This will list the contents of the backup - what you need is the first fields that tell you the logical names" - if your file lists more than two headers you will need to also account for what to do with those files in the RESTORE DATABASE command. If you don't indicate what to do with files beyond the database and the log, the system will apparently try to use the attributes listed in the .bak file. Restoring a file from someone else's environment will produce a 'The path has invalid attributes. It needs to be a directory' (as the path in question doesn't exist on your machine).
Simply providing a MOVE statement resolves this problem.
In my case there was a third FTData type file. The MOVE command I added:
MOVE 'mydbName_log' TO 'c:\temp\mydbName_data.ldf',
MOVE 'sysft_...' TO 'c:\temp\other';
in my case I actually had to make a new directory for the third file. Initially I tried to send it to the same folder as the .mdf file but that produced a 'failed to initialize correctly' error on the third FTData file when I executed the restore.
The .bak file from SQL Server is specific to that database dialect, and not compatible with MySQL.
Try using etlalchemy to migrate your SQL Server database into MySQL. It is an open-sourced tool that I created to facilitate easy migrations between different RDBMS's.
Quick installation and examples are provided here on the github page, and a more detailed explanation of the project's origins can be found here.