I'm enjoying FSharp.Data.Sql for tests. However I have two problems. As per the sample:
type sql =
SqlDataProvider<
dbVendor,
connString,
IndividualsAmount = indivAmount,
UseOptionTypes = useOptTypes>
a) the compiler keeps resolving the type every time there are changes in the code, making intelisense a bit too slow and also requiring permanent Internet connectivity.
b) having the host, user, and password in code might be convenient for tests and learning but that should never go into production code, ideally those would be environmental varaibles, but FSharp data expects literals.
Is it possible to freeze the type so that at least it is only resolved once and then provide the connection string in runtime?
For your first question, I believe SQLDataProvider is an erasing type provider, so you won't be able to do this. For other type providers it's sometimes possible to generate a dll and refer to that.
Regarding the database performance it's possible to tune it, but that will depend on the underlying driver, for example for Postgres.
For the second question, you can specify the connection string in the app.config file.
There are other ways to access the DB, for example Dapper or EF Core.
Related
I saw an example of how to create asp.net mvc application using masstransit messaging.
What I do undersatnd:
asp.net mvc controllers are meant to pusblish events;
whereas responses come from other (rabbitmq) queue hosted in a separate assembly via SignalR/or any other transport;
each queue (jobs, db writes, responses) is hosted in a separate console project/windows
service.
What I don't undersatnd:
whether separation of reads and writes is necessary?
the example uses mongodb which I still can use. So it doesn't get problematic to even separate reads and writes. But what about SQL Server/EF? How would you build/share db access across multiple assemblies? Should each queue assembly host its own DbContext?
If you were to use SQL Server and EF then yes, each process would have it's own DbContext instance to access the the database. It would be the same shared type across all processes. That's not a problem at all. I would define the EF domain in a shared assembly though. Breaking apart reads and writes isn't an issue at all.
Breaking apart reads and writes isn't really necessary, esp. at first. However, it can become needed as you scale up and have other concerns mixed in or additional scale. Breaking apart reads and writes is just a useful tool in modeling the software you need to write. It's not a requirement at all.
I am receiving SAP broadcasts, which I can normally use and play using the standalone vlc application.
I have been asked to provide a dump of the same. I have 2 questions:
I dont clearly understand what exactly dump is
How can I obtain the same?
There are multiple types of dumps, so you might first find out, what kind of dump is meant. It could be a database dump, which is similar to a backup, but usually it's a memory dump.
A memory dump or crash dump is a copy of the application including its memory at a specific point in time. Usually you want to create a dump exactly at the time an application is crashing or hanging. The dump will then be helpful to find the cause of the problem.
There are many ways to obtain a dump. First, Windows might do that for you, when it asks "Send information to Microsoft". Second, you can create it using Task Manager. Right click a process and choose "Create dump file". Third, there are many tools out there, e.g. Process Explorer or ProcDump, which all have pros and cons and serve different purposes.
To suggest a tool for your specific case, we would need more information. Exact wording might matter in this situation.
Update
In your particular case it looks like SAP means Service Advertising Protocol, which is related to the network. A broadcast is a message which is sent to everybody.
You could capture that one with Wireshark, but you would need a lot of network knowledge to get the filters set up. In this case the term "dump" probably refers to a something similar to a database dump, because SAP uses tables to store lists of services.
Good evening.
I'm looking for a method to share data from my application system-wide, so that other applications could read that data and then do whatever they want with it (e.g. format it for display, use it for logging, etc). The data needs to be updated dynamically in the method itself.
WMI came to mind first, but then you've got the issue of applications pausing while reading from WMI. Additionally, i've no real idea how to setup my own namespace or classes if that's even possible in Delphi.
Using files is another idea, but that could get disk heavy, and it's a real awful method to use for realtime data.
Using a driver would probably be the best option, but that's a little too intrusive on the users end for my liking, and i've no idea on where to even start with it.
WM_COPYDATA would be great, but i'm not sure if that's dynamic enough, and whether it'll be heavy on resources or not.
Using TCP/IP would be the best choice for over the network, but obviously is of little use when run on a single system with no networking requirement.
As you can see, i'm struggling to figure out where to go with this. I don't want to go into one method only to find that it's not gonna work out in the end. Essentially, something like a service, or background process, to record data and then allow other applications to read that data. I'm just unsure on methods. I'd prefer to NOT need elevation/UAC to do this, but if needs be, i'll settle for it.
I'm running in Delphi 2010 for this exercise.
Any ideas?
You want to create some Client-Server architecture, which is also called IPC.
Using WM_COPYDATA is a very good idea. I found out it is very fast, lightweight, and efficient on a local machine. And it can be broadcasted over the system, to all applications at once (to be used with care if some application does not handle it correctly).
You can also share some memory, using memory mapped files. This is may be the fastest IPC option around for huge amount of data, but synchronization is a bit complex (if you want to share more than one buffer at once).
Named pipes are a good candidates for local. They tend to be difficult to implement/configure over a network, due to security issues on modern Windows versions (and are using TCP/IP for network communication - so you should better use directly TCP/IP instead).
My personal advice is that you shall implement your data sharing with abstract classes, able to provide several implementations. You may use WM_COPYDATA first, then switch to named pipes, TCP/IP or HTTP in order to spread your application over a network.
For our Open Source Client-Server ORM, we implemented several protocols, including WM_COPY_DATA, named pipe, HTTP, or direct in-process access. You can take a look at the source code provided for implementation patterns. Here are some benchmarks, to give you data from real implementations:
Client server access:
- Http client keep alive: 3001 assertions passed
first in 7.87ms, done in 153.37ms i.e. 6520/s, average 153us
- Http client multi connect: 3001 assertions passed
first in 151us, done in 305.98ms i.e. 3268/s, average 305us
- Named pipe access: 3003 assertions passed
first in 78.67ms, done in 187.15ms i.e. 5343/s, average 187us
- Local window messages: 3002 assertions passed
first in 148us, done in 112.90ms i.e. 8857/s, average 112us
- Direct in process access: 3001 assertions passed
first in 44us, done in 41.69ms i.e. 23981/s, average 41us
Total failed: 0 / 15014 - Client server access PASSED
As you can see, fastest is direct access, then WM_COPY_DATA, then named pipes, then HTTP (i.e. TCP/IP). Message was around 5 KB of JSON data containing 113 rows, retrieved from server, then parsed on the client 100 times (yes, our framework is fast :) ). For huge blocks of data (like 4 MB), WM_COPY_DATA is slower than named pipes or HTTP-TCP/IP.
Where are several IPC (inter-process communication) methods in Windows. Your question is rather general, I can suggest memory-mapped files to store your shared data and message broadcasting via PostMessage to inform other application that the shared data changed.
If you don't mind running another process, you could use one of the NoSQL databases.
I'm pretty sure that a lot of them won't have Delphi drivers, but some of them have REST drivers and hence can be driven from pretty much anything.
Memcached is an easy way to share data between applications. Memcached is an in-memory key-value store for small chunks of arbitrary data (strings, objects).
A Delphi 2010 client for Memcached can be found on google code:
http://code.google.com/p/delphimemcache/
related question:
Are there any Caching Frameworks for Delphi?
Googling for 'delphi interprocess communication' will give you lots of pointers.
I suggest you take a look at http://madshi.net/, especially MadCodeHook (http://help.madshi.net/madCodeHook.htm)
I have good experience with the product.
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.
I have a media application (written in Delphi 2010 but I am not sure that's entirely relevant) and it only allows one instance (via mutex).
One of my customers would like to run 2 instances of the app by duplicating its install and all of its application data as this will allow him to run the output to two different sound cards, giving him two audio zones.
Now I can allow the second instance via command line switch, thus creating a differently named mutex and even allowing him to send controls to either instance of the appliction via command line switches or windows message passing.
My application also exposes a COM interface for automation purposes, obviously this provides a much richer interface than command line and makes it much easier to get information out of the application.
So my problem is that, as far as I am aware, I can only expose the COM interface to one executable. Now I know that makes sense, but I am wondering if anyone can think of a workaround to this.
I had a quick try at duplicating the registry keys for my HKLM\Software\Classes\AppID thus making AppIDv2 and got as far as it lanching the other copy of my app, but I guess it all came unstuck when it hit the more specific GUIDS for the TypeLib etc. Mind you, I know I overstepped the bounds of my knowledge!
My thought is that if I can create a different AppID string and ultimately target the exe sitting in different locations then we'd at least be able to do some automation via scripting COM Automation but I suspect that the requirement for GUIDs is ultimately going to let me down.
Another option may be to move my COM to inprocess and then have multiple compiled versions of my application that expose an instance of the main interface via new AppIDs, but that gets messy when you want the DLL to know all about the running instance of your application.
Any ideas welcome. Thanks in advance.
It sounds like you want to register yourself in the Running Objects Table (ROT).
i'm likening your problem to that of multiple copies of Excel running. COM has a mechanism to allow someone to find my the running instances of Excel and connect to one of them.
Out of process COM objects are expected to register themselves with the ROT. Callers can then use GetActiveObject to find your instance:
To automate an Office application that is already running, you can use the GetActiveObject() API function to obtain the IDispatch pointer for the running instance. Once you have this IDispatch pointer for the running instance, you can use the methods and the properties of the running instance.
You might not like it, but i believe the solution is that there is one application interface, and that "first" application acts as the gateway to other "instances" of your application (i.e. your automation server).
i'm not an expert in out-of-process COM automation, but i think i've read enough to believe that's the (unfortunate) answer.
See also
Registering the Active Object with API Functions
How To Attach to a Running Instance of an Office Application
You do indeed need the Running Object Table (IRunningObjectTable). Ian's answer is largely correct.
http://msdn.microsoft.com/en-us/library/ms695276(v=VS.85).aspx
However, it is possible to have two distinguishable instances in the ROT, allowing both copies of your app to be accessed because their monikers are distinguished.
Martyn