I'm in the process of converting a Paradox database application written in Delphi to use SQL Server 2008 R2. We are using the UNIDAC components from Devart to access the database/tables. However, I am finding the performance rather slow. For example, in the Paradox version it is more or less instant when it opens up a table (Using TTable) with 100,000 records, but the SQL Server (Using TUniTable) take approximately 2 seconds. Now I know this doesn't seem a lot but there are 10 TUniTable datasets which open up on form creation, all of which contain around the same number of records, so at present it is taking just under 20 seconds to open them all. Does anyone have any performance tips?
I'm using Delphi 2007
IMHO, UniDAC TUniTable is just a wrapper of TUniQuery. TUniTable open may lead to fetching all records on SQL Server. Not sure how, but try to change SQL Server cursor type and/or location.
If it is not late, then consider to use AnyDAC and TADTable. It uses "Live Data Window" technology, which allows to open and browse through the large tables without significant delays, eg Open and Last calls will be always fast. We migrated few BDE applications to AnyDAC and Firebird, TADTable works really great.
Related
unfortunately i have to work with ancient piece of software, that uses paradox tables.
The following code gives me exception:
fdcMainPX->TxOptions->AutoCommit=false;
fdcMainPX->StartTransaction(); <---
"Project xxx raised exception class EFDException with message '[FireDAC][Phys][ODBC]-303. Capability is not supported'"
It appears, that windows odbc driver for paradox doesn't support transactions. I suppose that ole jet engine allows transactions with paradox but i'd rather use Firedac over ADO or BDE.
How to set up connection with firedac to use MS Ole db ?
Maybe there is another way?
I am using C++ Builder XE6 Pro with Firedac
Paradox DBMS doesn't seem to be capable of transactions at all (maybe its new version, part of the Corel product is, but that doesn't seem to be your case).
However, if you just want to keep consistency of certain data batches in a single connection session, you can use cached updates.
I have an application in my company. I want to convert it from BDE to ADO Connection.
I searched almost everywhere, I did not find any good answer.
The AIM IS
Convert that BDE connection to ADO connection but we need to use TQuery component to fetch data from database.
So, it will look like we are using BDE but internally it uses ADO Connection.
So, please answer this question you cant imagine, how thankful i will be.
... if somehow we can set the database Alias to ADO connection ...
Just take a look at the source code of Delphi's BDE and ADO support (in e.g. DBTables.Pas and ADOInt.Pas + ADODB.Pas and you will soon see that they are as different as chalk and cheese.
You have no hope of e.g. using a TAdoConnection via the BDE from a Delphi app.
What you could do is do move your data to an ADO database (e.g. MS Sql Server) and then create a) a System DSN to connect to the ADO db via ODBC and then b) set up a BDE Alias that uses the BDE alias and c) change your existing BDE app to use the new alias instead of the one it currently uses. That way, you can continue using your existing app to access the ADO version of the data via TTable, TQuery etc and develop a parallel TAdo-component based equivalent at your leisure.
You could easily try this out using the traditional Delphi MastApp or "Fish Facts" demo application and data. Getting your existing BDE app to access an ADO-compatible copy of your data via an ODBC alias should not be more than a day's work even if you have never done it before. Actually converting your BDE app to ADO would likely take rather longer, though.
There are countless examples of different ways of copying BDE (e.g. Paradox) data to ADO data on the internet. Try looking at a few.
Delphi Xe2 + ZeosLib 7.0.3 Stable + Firebird 1.0
I am doing updates to the several tables and data is retaining on memory. It is not reflected on the database in a way that other applications can see it.
I have tried using auto-commit only and did not work.
I have also used explicit transaction control, ZConnection.StartTransaction and ZConnection.Commit and did not work either.
I am updating data in a webserver created on delphi with Indy httpServer. I get post requests then act reading or updating the database. The connection is stateless, however it is maintained a list of client apps that are connected and an a instance of ZConnection for each client to have isolation since the requests are threaded.
Besides that I am having the problem of not saving having only one client connected and doing one request per time, no overlapping or re-entrance.
I need to hear advice on using this scenario of Firebird, What I should do to make the commit work.
Has somebody real experience with firebird databases over the internet?
I have a typical windows accounting/ERP software (done with delphi) that works with the firebird database server pretty well.. Now my users (300 aprox. now, but should increment) also want to work "in the cloud" (connecting from the office, from the laptop, from the house, etc.). It is a lot of work of recreating everything to a standard web application (let's say for example, HTML+CSS+JS+PHP+MYSQL), so I'm considering keeping the win client (I don't care about other OSes) but instead of the server living in the clients LANs moving it to a pair of dedicated servers that I will contract (one primary and one secondary againts failures for starting).
Searching I've come across this faq http://www.firebirdfaq.org/faq53/ that explains that the fb protocol it isn't ideal for working in the internet, but still all my users today have at least a 1MBbit/sec ADSL internet connection (I don't think that to be slow as the faq denotes).
Somebody have done this? what was the experience? how secure are fb servers for being open to the internet? how well they scale?
I know that building a "middleware" with SOAP for example will be more normal, but still the solution I'm evaluating here is much more fast and easy (still I have some work with the replication, backup, hearbreath services, but it's much less than redoing everything for the web).
Thanks! Edit: FB version: 2.5.
I had being trying to "push" the Firebird Core developers to improve the Firebird protocol to get better speed with high latency network (aka. Internet). Recently, Dmitry Yemanov published some articles in his blog about this subject (dyemanov.blogspot.com). It seems that there is margin for optimizations, and I would really like to see this coming in FB 2.5.3 and FB 3.0, although there is no warranty for this happening in those versions or anytime soon. You can vote in such improvement here: http://tracker.firebirdsql.org/browse/CORE-2530
Safety? You may try to set up a VPN. It also may help with speed, since most of the VPNs software out there (Zebedee, etc) can compress the data being transfered, helping to speed up data transfer in some cases.
Some of my customers do use Firebird traditional C/S over the internet. It is much slower compared to local network, and of course, how much slower depends basically on the link speed and latency. You can do some optimization at the client side too, using metadata cache, etc. but don't expect miracles with the currently protocol. I would say that for whole day working, using Terminal Services would be a better option for now.
The response about the scaling question
Firebird runs in production on large big iron servers : 512G of ram 100.000 concurrent users
We run Firebird to power larger systems (for 12 government agencies
and 3 banks). It has approximately 100000 end users multiplexed
through 2500 (max) pooled connections
https://plus.google.com/111558763769231855886/posts/Q1ACy1yyTgP
The protocol in Firebird 2.5 is improoved there is still room left for 3.0 but you can check
what is already done
http://asfernandes.blogspot.com/2009/07/network-latency-influence-on-firebird.html
And the future enhancements in 3.0
http://www.firebirdnews.org/?p=6953
To protect your connection i guess the best bet is ssl/ssh tunnel (it can be a opnvpn)
with high compression option
http://mapopa.blogspot.com/2010/11/securing-firebird-using-ssh-tunnel.html
FB protocol problem isn't about bandwidth, but latency. In my experience, some operations can be very slow over internet/VPN compared to LAN or local connection. I haven't examined issue further since I don't really run applications over internet connection.
However, I suggest three-tier model for application. Create own application server, which runs on database server/same network. Let the clients talk with application server and you get maximum performance.
There are some N-tier application/middleware frameworks for Delphi:
RemObjects SDK and DataAbstract
RealThinClient
kbmMW
Delphi's own DataSnap
MidWare
With those you can get data compression, encryption, binary messages (faster than SOAP) etc.
You can implement TCP/IP packets encryption/decryption directly in the firebird engine itself.
Personnaly, i have downloaded the Firebird 2.5 source code and injected secure tunnelization code directly in his low level communication layer (the INET socket layer). Now, encryption/decryption is done directly by the firebird engine for each TCP/IP packet both at the server side and the client side (fbclient.dll).
Then there is no need to re-structure the client application except adding one line of code that provide the secret key you choose to crypt communication to the fbclient.dll. The same secret key must be declared in the firebird.conf file of your server installation.
I have also implemented a proxy negociation solution in the fbclient.dll in order to allow to TCP/IP packets to pass throught any proxy server (like Microsoft ISA Server for example).
For us, this architecture is functional for more than one year in a real production system.
kbmMW CodeGear Edition is free but without source. It can be used for commercial apps.
Download it after registering at: https://portal.components4developers.com
In case you see certificate errors (you shouldnt but I know we have heard that some actually do), accept and ignore them. The site is valid despite the cert.error.
kbmMW CodeGear Edition contains a subset of kbmMW Professional Edition, but supports the following Delphi database API's:
Borland Database Engine
DBExpress
kbmMemTable
SQLite3
It supports binary, binary over HTML, XML and SOAP protocols in communication with clients.
It contains everything you need incl.
unified remote custom method invocation
unified remote dataset query, execute and data change resolving
unified database meta data handling and creation (tables, fields, indexes, generators/sequencers)
optional automatic proxying of requests to another server and proxying results back to original requester
full native XML DOM and SAX support
full dataset briefcase support as CSV, or binary data
advanced but simple to use wizard for creating new application server services
THere is one caveat though. Newest version of kbmMW CodeGear Edition always only supports newest Delphi version. You can still download older kbmMW CodeGear Editions matching older Delphi releases.
kbMMW Professional Edition and kbmMW Enterprise Edition do not have such limitations, and currently supports D7, D2006, D2007, D2010, DXE, DXE2 along with Embarcadero C++ counterparts.
best regards
Kim Madsen
www.components4developers.com
What is the difference between ADOTable and ClientDataSet?
Both components are capable of performing Batch Update, why add the extra overhead of having 2 additional components like ClientDataSet and DataSetProvider.
The main difference is that ClientDataSet can operate without a connection to external database. You can use it as in-memory table or load it's contents from file.
In combination with DataSetProvider it is frequently used to overcome limits of unidirectional datasets and as a cache.
A ClientDataSet is an in-memory dataset, which has a lot of usefull additional functionallities.
One big advantage compared to Interbase/Firebird tables and queries is, that you don't need to keep a transaction alive, e.g. as long as you display the data in a grid.
Have a look at this article:
A ClientDataSet in Every Database Application
Client dataset is a generic implementation that works regardless of the underlying db access library. It can work (through the provider) with any TCustomDataset descendant, be it a dbExpress dataset, a BDE one, an ADO one, or any of the many libraries available for Delphi to allow for direct database access using the native client (i.e. ODAC, Direct Oracle Access, ecc. ecc.)
It can also work in a multi-tier mode where the data access dataset and provider are in a remote server application and the TClientDataset is in the client application, allowing for "thin client" deployment which doesn't require database clients or data access library like ADO installed on the client (the required midas.dll code can be linked to the application when using recent versions of Delphi, anyway only the midas.dll is required otherwise).
On top of that it can be used as an in-memory table able to store data in a local file. It allows for the "briefcase" model also, where a thin client can still work when not connected to the database, and then "sync" when a connection becomes available. That's was more useful in the past, when wireless access was not common.
As you can see, TClientDataset offers a lot more of a TADODataset.
The most important difference I can think of is resolving update conflicts. In fact, TClientDataSet exposes the handy ReconcileErrorForm dialog, which wraps up the process of showing the user the old and new records and allows them to specify what action to take, while with TADOTable for instance, you're basically on your own.