I have a 3-tier application written in Delphi 7 that uses a WebBroker-based SOAP server (standalone exe) with the SOAP client program communicating to via a HTTPRIO component.
This is not a DataSnap application. Instead the server sends data to the client as a disconnected ADO recordset in ADTG format that corresponds to the SQL string passed into the SOAP request. (The server first compresses it and converts it to Base64 for easy transmission back to the client as a "string" result.)
I use the returned recordset directly to iterate through its rows and fields (ie without needing to use a DataSet component) as this is something I am comfortable doing due to many years programming in Microsoft Access with VBA.
Luckily it is also possible to assign it directly to the Recordset property of a TADODataset component so that I can bind it to a QuickReport.
I now want to upgrade my client program to FireMonkey so that I can compile it for both Windows and OSX and suppose that I won't be able to use ADO Recordsets anymore, at least not in the Mac enviroment.
In preparation for conversion to FireMonkey, what would be the best data format that I can
a) disconnect and transmit "by hand",
b) load into a dataset component so that I can base reports on it, and
c) if possible, work through the data in code without having to first load it into a component?
This last item is important to me not just because I am used to working with data without using components, but also because I frequently request data in a thread in order to retrieve it in the background without locking up the user interface. As I understand it, components and threads don't go together.
Any advice about the best way forward?
I would go into transmitting some per-representation value, e.g. real XML or JSON, instead of some binary base-64 encoded content. And switch to a REST approach, which is much easier to implement on both sides than SOAP.
You can then fill a TDataSet from a JSON array of objects, or a JSON array of values (if you don't want to transmit the column names as object field names over the wire).
The advantage of JSON/REST is that you may be able to reuse the very same server logic for publishing its content to a HTML5 javascript client (mobile or web), or a third-party application or service.
Related
New to Delphi. I'm developing an application that needs to access a MSSQL database, to do this I've used an FDConnection, FDQuery and a DataSource component connected to a grid. With these I can access/modify/delete data just fine. Now if for example I want to filter the grid, I can do this by changing the FDQuery component at run-time, but I'm not sure if this is the right approach.
I've thought about using something that stores tables in memory like ClientDatasets because I'm not sure if FDQuery does this, so that I can manage data I've already retrieved without accessing database more than needed. My problem is I don't have a fundamental understanding of any of these components, so my question is:
Do I need to use anything else other than FDQuery?
A little more context on what I'm building: UniGUI web application, with the MSSQL server in the same LAN as the Web Server, and multiple user access to DB.
Now that I understand these components better, I found this FAQ from Embarcadero's doc that explains what I wanted to know.
Q1: Can I use TFDQuery and connect it to a dataset provider and retrieve the data in an Embarcadero client dataset?
A: TFDQuery is a mix of TFDMemTable, TFDTableAdapter and several
TFDCommand's. So, TFDQuery has everything inside to execute SQL
commands, send parameter data, receive and store result sets, browse
result sets and post changes back to a database. There is no reason to
use TFDQuery + DSP + CDS.
You can use TFDMemTable, TFDTableAdapter and TFDCommand directly,
instead of TFDQuery. They give more flexibility, but also require more
coding. Take for example synchronized cached updates across datasets.
In other words, TFDQuery is an optimal "shortcut" for every day data
application programming.
I'm looking to create an iOS app that communicates with a Windows app (also made by me). I've created some basic iOS apps in the past but I'm looking for assistance on the specifics of communicating with a Windows device.
Much like how a "remote mouse" application would work (where you install an iOS app and download the partnered Windows installer, which then talk together) I am looking to have my app search and then communicate with a program installed on a local network.
Is there a framework or recommended path to take when designing an app of this kind? The app itself will simply relay information available to the program installed in Windows as a proof of concept and then extra functionality will be added later. I'm primarily focusing on creating a working foundation where the iOS app and Windows program speak over the LAN.
I have implemented something similar to what you are describing using TCP sockets. Socket is a stream of raw bytes, after establishing a connection successfully between two ends, a socket may send or receive some bytes, there is no specific logical rules to define what you are sending or receiving, these bytes could represent anything, that is, you must define your protocol or structure of messages you are sending and receiving within your code logic to have meaningful messages at the end.
For example of a simple protocol, if you want to send a message (that message could be string, integer or anything) you send four bytes that represents an integer which specify the size of actual message (which has been serialized to bytes), then you send the actual message bytes, at the other end you read four bytes, which you know that they are representing the actual message size, now you know that you are expecting a specific number of bytes which represents a full message, so you keep reading bytes until you get all of these bytes to have a valid message. After receiving a message, you wait for another four bytes which represents new message size, and so on.
The message itself could be any serializable data type. Most programming languages supports serializing primitive types by default, if you want to serialize custom data type, one option is to encode your message (which, for example, is an instance of a struct that conforms to Codable protocol) using Swift JSONEncoder, so at the other end you expect a JSON bytes, which you can then decode them back to the original object. Another good option to serialize structured data is protobuf.
You may have a look at this class written in C#, it is a similar implementation of what I have described here, it is a bit different, but you will get the idea.
Note: default bytes order (endianness) may differ depending on the platform and programming language, it could be little-endian or big-endian.
CocoaAsyncSocket is a good library for dealing with sockets in iOS.
I have a 3rd party program which collects information and then sends the data to a non-text file. Normally I would access the data file after writing, however I now wish to access the incoming data so I can perform live calculations on it. To access the live data I can only think of attempting to access the file but do not have any idea how to do so whilst it is being written.
Is there any way in Delphi to read a file while it is being written?
Is there any other way of accessing the live data?
I have a form with a dbgrid and an sqlquery component. I am trying to fill the dbgrid with the sqlquery. When I do I get the message, "Operation not allowed on Unidirectional dataset." I do NOT want to use a client data set, as I do not want a 'local' copy of the data, I would like to read and display the data directly. How can this be done?
The documentation clearly states (emphasis added):
TSQLQuery is a unidirectional dataset. Unlike other datasets, unidirectional datasets do not buffer multiple records in memory. Because of this, you can only navigate using the First and Next methods. There is no built-in editing support: you can only edit the data in an SQL query by explicitly creating an SQL UPDATE command or by connecting the dataset to a client dataset using a provider.
Because there's no buffering of multiple records, you can't move in any direction except forward, which means that the DBGrid could not display multiple rows or support scrolling.
(In fact, all of the DBExpress components are unidirectional, according to the documentation on Types of DBExpress DataSets.)
You'll have to either use a TClientDataSet or change from using DBExpress to some other method of accessing the data such as ADO instead, or display the data using something other than TDBGrid (like a TStringGrid) and implement your own internal storage. However, TClientDataSet doesn't have to be a disk file, if the amount of data you're retrieving is manageable in memory; all of the data can just stay there without being a "local copy" (an "in-memory dataset").
I'd like to perform the following:
1) Open a dataset (using TMSQuery, SDAC DevArt component)
2) caching the content to disk (imagine a list of cutsomers)
3) the next time I need to Open the dataset I will first populate it with cached data, then I will just Refresh it by calling TMSQuery.RefreshQuick method.
In this way I plan to obtain a substantial improvement in speed, because I don't need to retrieve records that I already retrieved in previous application runs.
How can I obtain this caching? I have many datamodules with TMSQuery, so somehow I would like to have a global routine that checks that everytime I try to Open a TMSQuery, if that query is somehow tagged i will try to restore from cache, call RefreshQuick, in case this fails I will call Open.
Can you please suggest?
(I use Delphi 2009 and SDAC 4.80)
you can use the TClientDataSet and TDataSetProvider components for this, connecting the components in this way.
TMSQuery->TDataSetProvider->TClientDataSet
The TClientDataSet is a very good alternative to persist and retrieve data from an disk.
see these links for more info about the ClientDataset
Using the MIDAS ClientDataset as a replacement for cached updates
A Guide to Using the TClientDataSet in Delphi Database Applications
Effective ClientDataSets and the BriefCase Model
You can do 2 things:
Make descendant of the TMSQuery component and override the Open function
(you search all you datamodule .dfm and .pas files with TMSQuery and replace with TCachedTMSQuery)
Detour/hook the TMSQuery.Open (runtime patching)