my problem is that when i use mysql to create database it described that it should create db.opt file, but it doesn't. How to fix that, i'm using mysql mysql-8.0.32-winx64 portable version
I have tried to enable that option innodb_file_per_table=ON in my.cnf file;
Also, i have tried to enable server with that argument "--skip-opt", and also imported it in my.cnf;
It seems that noone is faced that problem before and yeah i know that i doesn't really need that file it is just for my homework, by that file i should show that my databases have right CHARACTER SET and COLLATE.
For all that i using comand line interface.
MySQL 8.0 is working as designed. The db.opt file and other metadata files are no longer used, because this version of MySQL implements metadata in a different way.
https://dev.mysql.com/doc/refman/8.0/en/data-dictionary-file-removal.html
The metadata files listed below are removed from MySQL. Unless otherwise noted, data previously stored in metadata files is now stored in data dictionary tables.
...
db.opt files: Database configuration files. These files, one per database directory, contained database default character set attributes.
I have no idea what homework you would be doing that requires direct access to db.opt. That file is normally only used by internal code of MySQL 5. I've been using MySQL since 2001, but I've never had any need to read that file directly.
I accessed .idb file from data store of mysql,even if database is password protected.
So if we can access Mysql database using .idb and .frm file without password then whats the use of database password??
it is important to consider that if you have physical access to the file system then all bets are off. there will always be some piece of 3rd party software etc that will unscramble some database file.
the point of a mysql password is to allow access through the allowed pathways to the MYSQL server.
to put that in context, a normal user or administrator of a website that is powered by php and mysql would never see or have access to the physical database files. The password level access set up in PHP and MySQL would only allow the application (php) to access what is required.
Securing the database files themselves should be done at the operating system level, granting the level of user access you require.
I've taken over an old software project which uses an MS Access database to store its data. However the database won't open in Access as it says:
"You do not have the necessary permissions to use the 'database.mdb' object. Have your system administrator or the person who created this object to establish the appropriate permissions for you."
But I have no idea how to do this and googling reveals almost nothing (it seems restricting access to Access databases it not something that's done very often!). The only other clue I've got is there's a .MDW (workgroup) file in the same folder, but I don't know if (or how) this relates to the main database as it has a different filename and also doesn't open.
How can I get access to this database? Is it likely to be password protected or just some kind of permissions problem?
The chances are pretty good that the .mdw file is the workgroup file for that .mdb database. (The .mdw file does not need to have the same name as the .mdb file because several different .mdb files can all share the same workgroup security settings.)
To access an .mdb file that has user-level (workgroup) security enabled you need to open it using a shortcut (or command-line invocation) of the form
"C:\Program Files\Microsoft Office\Office14\MSACCESS.EXE" "C:\Users\Public\uls\ulsTest.mdb" /WRKGRP "C:\Users\Public\uls\Security.mdw"
For a more detailed write-up, take a look here.
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.
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.