I need some help for interrogating an xlsb database (file) from a VCL C++ program; (using C++Builder XE2) mainly, i would like to query the data inside for simple viewing (its on the same machine, no networking involved), and i don't need to modify it ! so i would like to know :
Which control to use for connecting to an xlsb database
(TDatabase, dbExpress ?)
How to use that control for the purpose
of reading the data, (same as SQL?)
The difference between the regular xsl and xslb, and are they used in the same manner ?
I did some research before asking, but the information about that is pretty scarce !
(i'm on Win 7 64bit)
Thank you all !
Never tested it with these files but i believe you can use a TADOConnection and then user Microsoft OLE DB Provider for ODBC Drivers as the data provider, i know it can use access and excel files as a source, personally i have only ever used it for access files, but it might do what you want.
(Interbase ToGo is an embedded version of the InterBase sql database.)
I am doing a simple evaluation of InterBase ToGo by accessing it from a Windows 7 app. However, when I run my application I get a popup saying "product INTERBASE is not licenced.". Dismissing the popup terminates my application.
I have carefully examined the files being opened using Sysinternal's Process Monitor tool, and as far as I can see the license files I got from Embarcadero (the company behind InterBase) are being read from the correct paths.
I also have over 80 days left of my 90-day trial license for IB ToGo, so that should not be a problem.
Has anyone gotten InterBase ToGo to work lately when using a trial license?
This works after all. The problem may likely have been that only one connection may be active at a time on an InterBase ToGo database. I may have had the database open in Rad Studio at the same time as I was trying to use it from a running application.
In this case I created a simple application with Rad Studio XE3. I used VCL and dbExpress for creating the application. The steps were:
Create database file with the IBConnect tool. This ensures texts are UTF-8 encoded (non-english texts). Make sure char/nchar columns have charset utf8 for good measure.
Create project in XE3
Add TSQLConnection and TSQLDataSet components to VCL form. Setup references amongst them.
Ensure "server charset" is utf8 on the connection.
Add a TStringGrid to the form
Create a livebinding from the Grid to to the Data Set.
Add an SQL statement to the Data Set, e.g. select * from customers
Ensure DataSet's Open() function is called.
The grid should now be filled with (example) data!
I have seen programs exporting to Excel in two different ways.
Opening Excel and entering data cell by cell (while it is running it looks like a macro at work)
Creating an Excel file on disk and writing the data to the file (like the Export feature in MS Access)
Number 1 is terribly slow and to me it is just plain aweful.
Number 2 is what I need to do. I'm guessing I need some sort of SDK so that I can create Excel files in C++.
Do I need different SDKs for .xls and .xlsx?
Where do I obtain these? (I've tried Googling it but the SDKs I've found looks like they do other things than providing an interface to create Excel files).
When it comes to the runtime, is MS Office a requirement on the PC that needs to create Excel files or do you get a redistributable DLL that you can deploy with your executable?
You can easily do that by means of the XML Excel format. Check the wikipedia about that:
http://en.wikipedia.org/wiki/Microsoft_Excel#XML_Spreadsheet
This format was introduced in Excel 2002, and it is an easy way to generate a XLS file.
You can also try working with XLS/XLSX files over ODBC or ADO drivers just like databases with a limited usage. You can use some templates if you need formatting or create the files from stratch. Of course you are limited by playing with the field values that way. For styling etc. you will need to use an Excel API like Microsoft's.
I'm doing this via Wt library's WTemplate
In short, I created the excel document I wanted in open office, and save-as excel 2003 (.xml) format.
I then loaded that in google-chrome to make it look pretty and copied it to the clipboard.
Now I'm painstakingly breaking it out into templates so that Wt can render a new file each time.
What is the best way to store application configuration in a Qt application?
If You store only list of name-value pairs QSettings class will suffice. It is cross platform and works well.
Check this page for more info:
http://doc.qt.io/archives/qt-4.7/qsettings.html
On the other hand if You have to store data in multiple tables (many params, many rows) I suggest You use Sqlite and QtSQL. Sqlite is ralational database that can be embeded in your application without the need of starting any servers or installing additional software. Sqlite sotres all tables in one *.db file. You can place each user's configuration in his home directory.
This link demonstrates how QtSQL library works:
http://doc.qt.io/archives/qt-4.7/sql-sqlstatements.html
Well, as you're using Qt anyway, why not using QSettings? You can use its default settings to save your configuration in platform specific default locations (e.g. Registry under Windows) or use it to write to classic INI files.
I'm just learning C++, just started to mess around with QT, and I am sitting here wondering how most applications save data? Is there an industry standard? Do they store it in a XML file, text file, SQLite? What about sensitive data that say accounting software would need to save? I'm just interested in learning what the best practices for this are.
Thanks
This question is way too broad. The only answer is it depends on the nature of the particular application and the data, and whether or not it is written in C++ has very little to do with it.
For example, user-configurable application settings are often stored in text files, but on Windows they are typically stored in the Registry. Accounting applications typically keep their data in a database of some sort.
There are many good ways to store application data (call it serialization).
Personally, I think for larger datasets, using an open format is much, much easier for debugging. If you go with XML, for example, you can store your data in an open form so that if you have file corruption issues (i.e. a client can't open your file for some reason), it's easier to find. If you have sensitive data in there, you can always encrypt it before writing it to file using key encryption. Microsoft, for instance, has gone from using a proprietary format to open xml in their office docs. They use .*x extension (.docx, .xlsx, etc). It's really just a compressed folder with xml files.
Using binary serialization is, of course, the industry standard at the moment for most standalone applications. Most likely that is because of the application framework they are using (such as MFC, which is old). If you take a look at most of the serialization techniques in modern application frameworks, XML serialization is very well supported.
First you need to clarify what kind of data you would like to save.
If you just want to save some application settings, use QSettings to save your settings to an INI file or registry.
If it is much more than just some application settings, go for XML files or SQL.
There is no standard practice, however if you want to use complex structured data, consider using an embedded database engine such as SQLite or Metakit, or Berkeley DB files. XML files would also do the job and be human readable/writable. Preferences can use INI files or the Windows registry, and so on. In short, it really depends on your usage pattern.
This is a general question. Like many things, the right answer depends on your application and its needs.
Most desktop applications save end-user data to a file (think Word and Excel). The format is up to you, XML, binary, etc. And if you can serialize/deserialize objects to file it will probably make your life easier.
Internal application data such as configuration files or temporary data might be saved to an XML file or an lightweight, local database such as SQLite
Often, "enterprise" applications used internally by a business will save their data to a back-end database such as SQL Server or Oracle. This is so all of the enterprise's data is saved to a single central location. And then it is available for reporting, etc.
For accounting software, you would need to consider the business domain and end users. For example, if the software is to be sold to large businesses you would probably use some form of a database to save data. Otherwise a binary file would be fine, perhaps with some form of encryption if you are really paranoid.
When you say "the best way", then you have to define what you mean by "good".
The problem is that various requirements conflict with each other, therefore so you can't satisfy all of them simultaneously.
For example, if one requirement is "concurrent multi-user access to the data" then this suggests using a database engine, but that conflicts with "as small as possible" and "minimize dependencies on 3rd-party software".
If a requirement is "portable data format" then this suggests XML, but that conflicts with "compact" and "indexed".
Do they store it in a XML file, text file, SQLite?
Yes.
Also, Binary files and relational databases.
Anything else?