MySQL

zezo2021

Member
Local time
Today, 22:53
Joined
Mar 25, 2021
Messages
412
Hello friends;
What is the extension of MySQL (access for example mdb excel Xls)

How can I view these files via excel or access

please attach example of MySQL file can connect to access or excel
 
Hmm, I could be wrong, but I don't think MySQL is a file and therefore does not have a file extension.
 
View mysql data
How can I view these files via excel

Querying MySql DB with Excel VBA
 
RDBMS "files" are not plain text. You need to read them with some other program such as Access or Excel. MySQL probably has a GUI tool similar to SSMS but I don't know what it is called. However, you should be able to download it and use that.
 
RDBMS "files" are not plain text. You need to read them with some other program such as Access or Excel. MySQL probably has a GUI tool similar to SSMS but I don't know what it is called. However, you should be able to download it and use that.

Yes, and, that GUI may automatically associate itself to open files, once double-clicked, with a certain extension, such as SSMS will open .SQL files after a normal SSMS installation and all else being equal.

But any relational database GUI worth its salt will surely have a File > Open type of function you could use too, I would think?
 
Hello friends;
What is the extension of MySQL (access for example mdb excel Xls)

How can I view these files via excel or access

please attach example of MySQL file can connect to access or excel

Assuming your immediate need is to see the contents, and if we are correct in assuming that the type of file you are in possession of is merely the text of SQL in its essence, then just right click and open in Notepad.

As I've said, no matter how long I go, Notepad, Notepad++, and Paint are still my best friends.
 
But any relational database GUI worth its salt will surely have a File > Open type of function you could use too, I would think?
I'm not sure what you mean by this but technically (at least according to Codd) a RDBMS has a text interface so you can create objects programmatically. In Access you can use DAO, ADO, and in some cases native Access commands to manipulate objects of the RDBMS.

Access is the GUI for Jet and ACE. SSMS is the GUI for SQL Server. Other RDBMS's each have their own custom GUI's but they can also be manipulated via code.
 
What I mean is, if this person has "some" file that is supposedly for use in mysql, and if he uses a gui for mysql, that gui ought to have a file>open feature just like ssms does to open a .sql query file, at least I would assume any gui worth its salt would surely have that feature, wouldnl't you think.
 
I thought this thread would benefit from a link to this blog about shifting MS Access data into My SQL.


The interesting part was the use of an API to trigger "Laravel" a PHP framework to process the newly imported MS Access data.
 
The backup file for a SQL Server database is .bak So, SSMS can read the .bak and reconstitute the database. I never tried to open a .bak file with notepad so I don't know what it looks like. I'm guessing, it is not plain text.
 
RDBMS "files" are not plain text. You need to read them with some other program such as Access or Excel. MySQL probably has a GUI tool similar to SSMS but I don't know what it is called. However, you should be able to download it and use that.
I realise this is an old post but Pat's contribution most clearly demonstrates a misunderstanding about databases. (I expect Pat actually knows better but her explanation as it was written is wrong and will be misleading the database newcomers.)

Microsoft SQL Server Management Studio (MSSMS) cannot open a database file (.mdf). The file is opened by the MSSQL Server database engine which must be installed on a computer and runs as a service. The mdf file itself is not an RDMS.

MSSMS is a progam that connects to the database engine, sends text based commands to it and displays the results. That is what Pat is talking about in this post.
technically (at least according to Codd) a RDBMS has a text interface so you can create objects programmatically.

Although Access can open an mdb or accdb file, it only interacts with the Access objects in the file. It does not interact directly with the data in the tables or run the queries. That job is done using a database engine that is installed on the computer. That engine was originally JET which was part of the Windows operating system. Since the inception of the accdb format, Access now uses its own engine called ACE.
 
cannot open a database file (.mdf).
I can't argue with you about this but my backups are .bak. I guess we must be able to choose the extension and .mdf is probably the default.

I'm not sure which part of SQL Server actually "reads" the backup file but I reconstitute them using the SSMS interface.

Access provides a GUI for Jet/ACE much the same way that SSMS provides a GUI for SQL Server. Whether the GUI uses some intermediary software to actually access the database is a fine point that isn't relevant in a high level discussion. Yes, if you know how Access works, you know that the Jet and ACE engines are separate software and can be used independently of Access the RAD tool we use as our FE's so one would assume that Access the RAD tool when used as the GUI to build database objects is interacting with Jet or ACE on our behalf. You can use Access to build Jet/ACE queries and tables graphically or you can build them using text using either DDL queries or VBA using DAO or ADO. You can use SSMS to build SQL Server queries and tables graphically or you can build them using text - DDL queries (scripts) or possibly using ADO but that is not in my skillset.

Access the RAD tool is 100% dependent on Jet (.mdb) or ACE (.accdb) because all Access objects are stored within either an .mdb or an .accdb which are both a container type of file structure. So, even if the BE data is in SQL Server or some other RDBMS, it is still necessary to have Jet/ACE installed whereas, Jet and ACE can operate independently of Access the RAD tool and Access does not even need to be installed for some other programming tool such as vb.net or Java Script to use an "Access" BE. Calling both the FE and BE "Access" causes lots of confusion. Technically only the FE is Access. The BE is either Jet or ACE depending on the version.

The nice thing about SSMS is that you can have it build DDL for you. Access doesn't have that feature so for any of my BE's that I need to build a lot of DDL for, I just upload the tables to SQL Server and let SSMS build the DDL for me. It only takes minor changes to run the DDL in Access.
 
The backup file extensions are bak. The actual database files are mdf with the log are ldf. The bak file contains the data plus some of the logs, depending on the type of backup used. The default location of the mdf, ldf and bak files can be configured. The tables and other objects don't live inside SSMS.

I can assure you that the engine is what reads and write these files. Absolutely every action that can be done in SSMS can be done by sending a text SQL command to the database engine. That includes restoring the backups. SSMS is simply a graphic application that constructs the SQL commands, sends them to the engine and displays the returned results.

SQL Server can function completely without SSMS being installed at all and there are several alternative SQL Studios that also work with the engine.
 
It seems I was being sloppy with my "pronouns" I said "RDBMS files" but I was talking about the .bak specifically.
SQL Server can function completely without SSMS being installed at all
I don't think I implied that it couldn't. I was comparing the relationship between Access the Rad tool and Jet/ACE and between SSMS and SQL Server. Both provide a GUI interface which is superfluous unless you hate typing:)
 
The only comment I will make is that .BAK file extensions are not exclusive to databases. Many backup systems that make "containerized" user or enterprise-level backups of a file, folder, or partition of a disk will often create a .BAK file (analogous to a .ZIP file) to hold all the backed-up files together as a formal save-set. Therefore, I would question the actual meaning of a .BAK file with regard to what application is associated with it.

To see what .BAK means on an individual Windows system, use Start >> Settings >> Apps >> Default Apps and then look at the bottom for the link to "choose apps by file type" - which opens the "Associations" table that TELLS you what app runs for a given file type. As it happens, since I have neither a formal BACKUP program nor any variant of SQL Server, there IS no association for .BAK for me.
 
Actually, I lied about "the only thing I will say." Here is the architecture of SQL Server.


You will have one .MDF which is the primary metadata file. You may have multiple .NDF files which are secondary data files. However, it is also noted that the primary and secondary files can have ANY file extension. The layout of the data in an SQL server file is organized into file "extents" (essentially, groups of contiguous disk blocks) stored and optimized according many criteria. It may not be possible to directly read the secondary files even though they might contain the actual data you want. You have to be able to read the primary file, which contains the schema description and a pot-load of other stuff like file locations and such.

Therefore, @zezo2021, the only way to reliably read an SQL Server file is to have SQL Server itself on the machine to act as an intermediary in trying to analyze file contents. Unless, of course, you find a commercial utility that can read SQL Server files... but I don't happen to know of one.
 
However, it is also noted that the primary and secondary files can have ANY file extension.
As it is with any Windows file. The extension is just a convenient way to associate the file with a program. For example, MS Word files don't need the docx extension to be able to be opened by Word. Information about the nature of files (other than simple text files) is stored in the first line which is read by the program to tell it how to handle it.

SQL Server stores configurations for the connections between individual databases and the files that hold the data
 

Users who are viewing this thread

Back
Top Bottom