I opened up a Northwind database (northwind.sqlite3) using DB Browser for SQLite (Version 3.9.1).
For some product names, I couldn't get the right names displayed no matter what I did, including:
I changed new line characters options
I changed Preferences options
I checked the outputted csv using Excel and Notepad with different encoding
Still couldn't figure out how to properly show the characters...Any help is appreciated.
The problem may be either that data have been added to the database in an incompatible encoding (e.g., pasting data from Microsoft products into a UTF-8 database can do this) or that the DB Browser isn't displaying the data in the correct encoding. To fix the former problem you may have to edit the data, or possibly change the database encoding. You can't change the encoding of a SQLite database on the fly, so you would have to export the data and import them into a new database with the encoding that is actually used. If it's just a DB Browser display issue, right-click on the table header and choose the option to change the display encoding.
Related
I have a problem..
I work with ASP.NET and After I add a data (Arabic language) to my form via the browser it added to the SQL Server Management Studio like this (???????) even when I retrieve the data entered by the browser, Although there is no problem when I add my Arabic data via SQL Server Management Studio direct.
(there is no problem with English data)
Somewhere along the way your changing the charactertype to something else, that is probably Standart ascii.
It is impossible to know where exactly since we don't have hany information about that, but I would guess that in your Backend things are messed up, try commenting out your code and just echoing the values to see if they are already wrong at that stage.
Maybe change the Stringtype to utf-16
That should support any chars you throw at it
I'm working with a company trying to setup a new database system as their old database software has gone out of business. All the data is in a .fb file that is encrypted (You used to have to get backups 'unlocked' before they would let you use them).
I've managed to get a copy of the database (I think it's unencrypted as I copied it while the database was open and then changed the copied files permissions using terminal).
The problem is that it's a .fb file and I can't find a way to 'open' it to browse the data...
Any Ideas?
Generally speaking, data stored in relational databases aren't just stored as ascii csv files. So you won't be able to just open up a .fb file in a text editor and grab the data.
If you're still able to query the database, you will need to have the frontbase server generate a dump of the data into a flat file.
See the frontbase documentation for backup and restore. Specifically 4.9.1. Exporting Schema and Content Data:
WRITE ALL OUTPUT('<output-directory>' [,'YES']);
I inherited some old records for a company I volunteer for. One of the old files is an SQL Dump from their old webpage, and I would like to get the data from one of the tables for their use into Excel.
-- MySQL dump 10.11
The dump drops the table if it exists, creates the table new, and then inserts all of the data.
Is there some easy way I can get this data into Excel on my PC? I don't have SQL Server or anything like that loaded... I assumed there was some easy way to get a CSV or Excel file out of it but I have failed to find this yet without first uploading the dump to some SQL Server.
Unfortunately I don't think that there is any way to export a dump file into an excel or .CSV file. The reason for this is that the dump file is actually a collection of Select statements instead of the actual data itself. SQL servers do this to prevent a whole list of problems that can occur when you try to manipulate raw data manually.
Lucky for you, MySQL offers a free version of their server. You can find it here: http://dev.mysql.com/downloads/
I think you are best off downloading this and restoring your file as a new database. This has the added benefit of allowing you complete control over the data from that point on. Exporting to excel would be easy at that point however, you may find it a lot more fulfilling to continue using MySQL server.
Hope this helped.
Good Afternoon,
I am in the process of developing in vb.net a simple “cheque printing” application which will allow users to fill in a few text boxes with the values that will be printed on a cheque.
When they hit the print button, the values will be sent to the printer, but I also want the values they input in the text boxes saved to a file, so like a history file of all the cheques that were created.
I am thinking to use either an access database or an excel spreadsheet as my history file, but I am not quite sure on which would be best.
Please note that in my environment storing this information in a SQL database is not an option and also this file will most likely be stored/accessed from the network.
The history file needs to be:
1.Stable (cannot corrupt easy)
2.Reliable
3.Easily exportable in case we need to export the information to one of our in-house systems.
4.editable from the application I am developing
Kindly advise,
A
XML. Save the data to DataTable object and then use the .WriteXML method to save it as an xml file. I'd advise creating a strongly-typed DataTable class for this, so that the XML can be exported with a reliable schema and imported easily.
If you are using different fonts, you could use a .rtf (rich text format) which will save the format of the text that you send to print... it is a universal file format, you can open it with open office, ms office, or any office suite you have...
Access will be best choice,
it's relational database and can make a form from this file to do what are you looking for without VB or any code.
Also you can access this file from network.
for more detail about setting for this file go to this link
http://goo.gl/bOfGp6
and you will find more options complete your work.
I would use a MySQL server. It's free.
XML is also good, but I hate sharing folders...
I've been searching without luck for a MacOS iODBC driver that can read saved .SQL files exported in Microsoft SQL Server format. Does one exist?
We've got a large pile of research data stored in one app that can export as Excel spreadsheets or SQL files (eg, a text file full of SQL CREATE TABLE and INSERT statements). We need to import this data into another app (Stata 9) that runs under MacOS and can import Excel files, its own format, or from an ODBC source. So, I need an ODBC driver that can read plain SQL files as its source. We don't need a driver that actually talks to an MSSQL database, because there is no actual database here; just a plain .SQL file with MSSQL-style commands in it.
Unfortunately, the default MacOS install seems to come with no ODBC drivers whatsoever, not even one for reading flat files or SQLite databases.
The current workflow for moving this data — exporting it from DatStat as an Excel spreadsheet, opening that spreadsheet and fixing it by hand to conform to Stata's need, then saving and reimporting into Stata — is ridiculously labor-intensive and also loses a lot of important metadata like variable descriptions and annotations.
I think that best thing to do here is load the data from DatStat to a database and then load it back into Stata. First, export your data from DatStat to a .sql file. I'm not familiar with DatStat, but if you can do this in bulk or via the command line it would be best. You can access your OS's terminal in Stata by using the -shell- command. After you have a .sql file, say foo.sql, you can use the following Stata code to send it to a database and then import into Stata.
odbc sqlfile("foo.sql"), dsn("DataSourceName")
odbc load, exec("SELECT * FROM CustomerTable") dsn("DataSourceName")
You could even issue a final command to cleanup the tables in the database if you don't think you'll use this database again and you don't want it taking up space. Use something like:
odbc exec("DROP TABLE CustomerTable")
Yes, this will probably be slow if your dataset is large, but it could be nice once your data is in the database because you can query parts of it at a time instead of importing the whole thing.
Lastly, you mentioned that no ODBC driver for Mac exists for MS SQL Server. If that is the case, you may want to install one of the open-source database systems like MySQL or PostgreSQL. I'm not a Mac user but drivers for these must exist for mac.
Good luck!