We are using informix db on linux operating system.Is there a way we can know history of queries that have been executed through isql ?
The Informix server has a feature for SQL tracing that is enabled with the SQLTRACE onconfig parameter. This can be set to collect various levels of information relating to executed statements including the statement text. This is maintained in an in-memory circular buffer so the information would need to be extracted from this buffer and stored separately if you wanted to maintain a permanent history.
There is more information on this feature in the Informix Adminstrator's Guide at https://www.ibm.com/support/knowledgecenter/SSGU8G_12.1.0/com.ibm.admin.doc/ids_admin_1126.htm
Related
Is it a good idea to continuously use External Data Access (EDA) for synchronization of big files (let's say with 10 million records) with RDBMS. Will EDA also handle incremental updates to the source UniData file and automatically reflect those changes(CREATE, UPDATE and DELETE) to the target RDBMS system?
Also, according to the documentation, EDA supports right now MSSQL, Oracle and DB2. Is it possible to configure EDA to work for example with PostgreSQL?
What's difference between Apache Ignite and IWA (Informix Warehouse Accelerator) and Infinispan ?
I have an application that accept large volume of data and process many transaction in per second. Not only
response time is very important for us, but also Data integrity is very important for us, Which in-memory databases best solutions for me ? , I'm confused
to select them. also i use JEE and application server is jboss.
We are looking for best in-memory database solution to processing data in real time?
Update:
I use relational database , i am looking for in-memory database to select , insert , update from that for decrease response time, Also Data integrity is very important and very important persist data on disk
Apache Ignite and Infinispan are both data grids / memory-centric databases with similar feature lists, with the biggest difference that Apache Ignite has SQL support for querying data.
Informix Warehouse Accelerator seems to be a narrow use case product, so it's hard to say if it's useful for your use case or not.
Otherwise, there's too few information in your question about the specifics of your project to say if either of those are a good fit, or even none of them.
Does the DBMS save the compiled queries from prepared statements in JDBC, in the form of stored procedures on the DBMS server? I thought that prepared statement isn't a concept in DBMS but in JDBC, so I was wondering how it is implemented on DBMS server side.
My question comes from Why do Parameterized queries allow for moving user data out of string to be interpreted?
I read DIfference Between Stored Procedures and Prepared Statements..?, but don't find my answer.
Thanks.
I am interested in PostgreSQL, MySQL, or SQL server in order.
No, prepared statements are not implemented as stored procedures in any RDBMS.
Prepared statements are parsed and saved on the server-side so they can be executed multiple times with different parameter values, but they are not saved in the form of a stored procedure. They are saved in some implementation-dependent manner. For example, as some kind of in-memory object, totally internal to the code of the database server. These are not callable like a stored procedure.
Re your comment:
Consider MySQL for example.
MySQL in the very early days did not support prepared statements, so the MySQL JDBC driver has an option to "emulate" prepared statements. The idea of emulation mode is that the SQL query string is saved in the JDBC client when you create a PreparedStatement. The SQL is not yet sent to the database server. Then when you bind parameters and call execute(), it copies the parameter values into the SQL query and sends the final result.
I don't know whether a similar feature exists in other brands of JDBC driver.
in the tfs database Tfs_DefaultCollection
There are nearly no keys. (maybe none, as I haven't exhaustively searched)
I'm able to see all my work items, and current/previous states just fine. However when I join WorkItemAre to Tbl_Iteration none of the IterationIds match at all. How do I look at work items by iteration name/title?
my search code is as follows:
this.Tbl_TeamConfigurationIterations.Dump();
this.Tbl_Iterations.Dump();
var myPersonId= foo; // omitted from sample
var qIteration = from wia in WorkItemsAres.Where(x=>x.AssignedTo==myPersonId && x.State!="Closed" && x.State!="Resolved")
join iLeft in Tbl_Iterations on wia.IterationID equals iLeft.SequenceId into iL
from iteration in iL.DefaultIfEmpty()
select new {iteration.Iteration,wia};
qIteration.Dump();//.Select(x=>new{x.AreaID,x.IterationID, x.Title,x.WorkItemType}).Dump();
for those interested in the solutions (both direct db and tfs api dll calls):
Direct Db version
Proper Tfs dll calls
#Maslow,
you can use xxTree table to get iteration name (join with WorkItemsAre table on IterationID = xxTree.Id) but you should be aware that this is undocumented and unsupported way. I would strongly recommend using TFS object model to do such things.
Microsoft very strongly recommends against using the transactional database directly (in fact it can put you into an unsupportable state). If you want to query TFS Data is recommended to do so using the API and Client Object Model (SDK). There is a very rich API for interacting with TFS that is supported.
See the docs here: http://msdn.microsoft.com/en-us/library/bb130146.aspx
Here is something that came out of a private mailing list where we (ALM MVP's) were trying to better understand Microsofts stance on this:
Reading from the [TFS] databases programmatically, or manually, can cause unexpected locking within Microsoft SQL Server which can adversely affect performance. Any read operations against the [TFS] databases that originate from queries, scripts, .dll files (and so on) that are not provided by the Microsoft [TFS] Development Team or by Microsoft [TFS] Support will be considered unsupported if they are identified as a barrier to the resolution of a Microsoft support engagement.
If unsupported read operations are identified as a barrier to the resolution of support engagement, the database will be considered to be in an unsupported state. To return the database to a supported state, all unsupported read activities must stop.
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.