Error handling. This has caused me many problems in the past. When an error occurs, the event on the connection that is called does not seem to behave as documented. If I attempt a retry or opt not to display an error dialog, it does it anyway. In all fairness, I have never reported this. I think it is more important that a unique error code is passed to the error event that identifies a uniform type of error that occurred, such as ecDisconnect, eoInvalidField. It is very hard to find what any of the error codes currently passed actually mean. A list would be great for each database engine. Trying to catch an exception without displaying the UniDAC error message is impossible, no matter how you modify the parameters in the OnError of the TUniConnection object. I have already implemented the following things myself. They are suggestions rather than specific requests. Copy Datasets: This contains an abundance of redundant options. I think that a facility to copy one dataset to another in a single call would be handy. Redundancy: I am currently working on this. I have extended the TUniConnection to have an additional property called FallbackConnection. If the TUniConnection goes offline, the connection attempts to connect the FallbackConnection. If successful, it then sets the Connection properties of all live UniDatasets in the app to the FallbackConnection and re-opens them if necessary. The extended TUniConnection holds a list of datasets that were created. Each dataset is responsible for registering itself with the connection. This is a highly specific feature. It supports an offline mode that is found in mission critical/point of sale solutions. I have never seen it implement before in any DACs, but I think it is a really unique feature with a big impact. Dataset to JSON/XML: A ToSql function on a dataset that creates a full SQL Text statement with all parameters converted to text (excluding blobs) and included in the returned string. Extended TUniScript:- TMyUniScript allows me to add lines of text to a script using the normal dataset functions, Script.Append, Script.FieldByName(‘xxx’).AsString := ‘yyy’, Script.AddToScript and finally Script.Post, then Script.Commit. The AddToScript builds the SQL text statement and appends it to the script using #e above. Record Size Calculation. It would be great if UniDac could estimate the size of a particular record from a query or table. This could be used to automatically set the packet fetch/request count based on the size of the Ethernet packets on the local area network. This I believe would increase performance and reduce network traffic for returning larger datasets. I am aware that this would also be a unique feature to UniDac but would gain a massive performance enhancement. I would suggest setting the packet size on the TUniConnection which would effect all linked datasets.
