I have a related post - Assertion failure in DBAccess.pas but thought this was worth asking separately.
We are licensed for the full source-code release of DevArt ODAC but have been experiencing tremendous difficulties performing an upgrade. In the course of investigating this I have noticed that there is no .pas file for OraNet.dcu.
This is making it difficult to establish what the cause of our difficulties is as we cannot fully debug the code.
Also - what is this unit? From its name and the directives in the code it would be reasonable to suppose it is a .NET required unit - not something we are interested in.
There is the Direct DB connection mode implemented in the OraNet.dcu module, and we don't distribute the source code of this module, this limitation is specified at our website (the reference at the bottom of the page). If you don't use the Direct mode, and work via the Oracle client (the OCI mode), you can specify DEFINE NONET in your project settings, in this case, the Direct mode will be unavailable, and this module won't be used.
The client usage (even Oracle Instant Client) really allows using more features, than our Direct mode, but the Direct mode even surpasses OCI by performance in some cases. Besides, the Direct mode significantly simplifies application deployment and decreases the application size on disk due to the fact that there is no need to supply and deploy additional libraries, and set additional registry parameters and environment variables. The Direct mode also allows application deployment to systems, for which there are no native Oracle clients, for example, iOS. Choosing of the way of working with the DB (Direct or OCI) depends on developer and tasks resolved by each particular application. As it was mentioned above, if the Direct mode is not used, additional module plugging can be disabled by setting DEFINE NONET
Related
In which mode neo4j database should be used embedded or rest server?
My main concerns are :
Performance
Horizontal scaling (HA,Clustering) - essential as application is very big.
Transactional support(in frameworks like SDN,Grails Plugin,structr etc.)
Deployment server support like amazon,GrapheneDB etc.
Easiness of switching from one to another
Scaling(size of database)
Disclaimer: I'm one of the founders of GrapheneDB.
I'm not an expert in embedded mode so my answer might be biased but I will try my best:
Embedded is more performant at this time than server
Clustering is supported in embedded as well as in server
Transactional support is available in both modes AFAIK. Spring Data, however has currently bad performance over Rest/server.
From my POV embedded has the disadvantage of being coupled to your app/server deployment.
There is one more option which you haven't brought up, which is using unmanaged server extensions.
Using extensions you can get the best of both modes:
You write your code on top of the Java API and it's executed locally, so you get extremely good performance.
You can run the server in server mode, making operations easier and also enabling you to host on a separate remote host, on any cloud environment.
GrapheneDB supports unmanaged extensions and it's the option we currently recommend for scenarios where extra performance is needed.
I'm developing an application that is able to determine which application using internet. Now my problem is that i want to know the process name before it successfully establish connection much like a firewall.
I'm using Delphi2009. So the suggestions in that technology are appreciated.
Look at Winsock Layered Service Providers to monitor traffic. I believe LSPs are DLLs that get loaded into each process, so you should be able to call GetModuleFileName(NULL) to discover the EXE name when your DLL is loaded.
The Wikipedia article linked above shares my strongest concerns:
One major common issue with LSPs was that if they were to be removed
or unregistered improperly or if the LSP was buggy, it would result in
corruption of the Winsock catalog in the registry, and the entire
TCP/IP stack would break and the computer could no longer access the
network.
So if you are new to Windows programming and/or do not take proper precautions with writing these types of filter drives, then tread carefully. Otherwise, a bug in your program will easily screw up the user's machine.
Say I have a couple of java runtime environments running on my system which are used by several applications. I would like to programmatically interact with these applications by reading their memory.
A typical approach would be to directly look into this application's memory, however for java applications this seems to be practically impossible because of the java runtime environment. Instead, one has to look into the memory of the java runtime environment, or debug it.
[ the above is what I think I have learned from several searches on the web, if anything is false, please correct me ]
Note: keep in mind that the application I want to monitor is not owned by me and thus I do not have the source code nor the ability to launch the application in "debug mode" or something.
Now, as this is a non-production project, I would prefer an easy way out: using an existing windows GUI application which can already monitor variables of a java runtime environment and it's applications to programmatically crawl these from this GUI application for usage in my own project. If any such program exists, I would really appreciate the help.
If the above is not possible, how would I (programmatically) retreive these variables otherwise?
It's difficult to answer this precisely without knowing much more about the application involved, its structure etc. Note that objects move around in the JVM's memory, and so you can't monitor the actual application memory directly.
So the first question is, how do you know what you want to monitor without the source code ? e.g. which variables/objects etc.?
Given that you've worked this out, it strikes me that you have two options.
decompile and instrument the application (perhaps statically, perhaps using AOP), and recompile it. This assumes that the application is not obfuscated, and you're not in breach of licensing etc.
wrap the application in a thin layer that uses reflection to identify the variables you're interested in, and tracks the values of those variables as the process executes. I suspect you'll still have to decompile to identify these variables.
You can monitor these values remotely by creating an MBean and exposing via JMX, and monitoring via JConsole. That's pretty trivial compared to the initial step of finding those variables you're interested in.
The situation is simple. I've created a complex Delphi application which uses several different techniques. The main application is a WIN32 module but a few parts are developed as .NET assemblies. It also communicates with a web service or retrieves data from a specific website. It keeps most of it's user-data inside an MS Access database with some additional settings inside the Registry. In-memory, all data is converted inside an XML document, which is occasionally saved to disk as backup in case the system crashes. (Thus allowing the user to recover his data.) There's also some data in XML files for read-only purposes. The application also executes other applications and wants for those to finish. All in al, it's a pretty complex application.
We don't support Citrix with this application, although a few users do use this application on a Citrix server. (Basically, it allows those users to be more mobile.) But even though we keep telling them that we don't support Citrix, those customers are trying to push us to help them with some occasional problems that they tend to have.
The main problem seems to be an occasional random exception that seems to pop up on Citrix systems. Never at the same location and often it looks related to some memory problems. We've p[lenty of error reports already and there are just too many different errors. So I know solving all those will be complex.
So I would like to go a bit more generic and just want to know about the possible issues a Delphi (2007) can have when it's run on a Citrix system. Especially when this application is not designed to be Citrix-aware in any way. We don't want to support Citrix officially but it would be nice if we can help those customers. Not that they're going to pay us more, but still...
So does anyone know some common issues a Delphi application can have on a Citrix system?
Does anyone know about common issues with Citrix in general?
Is there some Silver Bullet or Golden Hammer solution somewhere for Citrix problems?
Btw. My knowledge about Citrix is limited to this Wikipedia entry and this website... And a bit I've Googled...
There were some issues in the past with Published Delphi Applications on Citrix having no icon in the taskbar. I think this was resolved by the MainFormOnTaskbar (available in D2007 and higher). Apart from that there's not much difference between Terminal Server and Citrix (from the Application's perspective), the most important things you need to account for are:
Users are NEVER administrator on a Terminal or Citrix Server, so they no rights in the Local Machine part of the registry, the C drive, Program Folder and so on.
It must be possible for multiple users on the same system to start your application concurrently.
Certain folders such as the Windows folder are redirected to prevent possible application issues, this is also means that API's like GetWindowsFolder do not return the real windows folder but the redirected one. Note that this behaviour can be disabled by setting a particular flag in the PE header (see delphi-and-terminal-server-aware).
Sometimes multiple servers are used in a farm which means your application can run on any of these servers, the user is redirected to the least busy server at login (load balancing). Thefore do not use any local database to store things.
If you use an external database or middleware or application server note that multiple users will connect with the same computername and ip address (certain Citrix versions can use Virtual IP addresses to address this).
Many of our customers use our Delphi applications on Citrix. Generally speaking, it works fine. We had printing problems with older versions of Delphi, but this was fixed in a more recent version of Delphi (certainly more recent than Delphi 2007). However, because you are now running under terminal services, there are certain things which will not work, with or without Citrix. For example, you cannot make a local connection to older versions of InterBase, which use a named pipe without the GLOBAL modifier. Using DoubleBuffered would also be a really bad idea. And so on. My suggestion is to look for advice concerning Win32 apps and Terminal Services, rather than looking for advice on Delphi and Citrix in particular. The one issue which is particular to Citrix that I'm aware of is that you can't count on having a C drive available. Hopefully you haven't hard-coded any drive letters into your code, but if you have you can get in trouble.
Generally speaking, your application needs to be compatible with MS Terminal Services in order to work with XenApp. My understanding is that .NET applications are Terminal Services-compatible, and so by extension should also work in a Citrix environment. Obviously, as you're suffering some problems, it's not quite that simple, however.
There's a testing and verification kit available from http://community.citrix.com/citrixready that you may find helpful. I would imagine the Test Kit and Virtual Lab tools will be of most use to you. The kit is free to use, but requires sign-up.
Security can be an issue. If sensitive folders are not "sandboxed" (See Remko's discussion about redirection), the user can break out of your app and run things that they shouldn't. You should probe your app to see what happens when they "shell out" of your app. Common attack points are CHM Help, any content that uses IE to display HTML, and File Open/Save dialogs.
ex: If you show .chm help, the user can right-click within a help topic, View Source. That typically opens Notepad. From there, they can navigate the directory structure. If they are not properly contained, they may be able to do some mischief.
ex: If they normally don't have a way to run Internet Explorer, and your app has a clickable URL in the about box or a "visit our web site" in the Help menu, voila! they have access to the web browser. If unrestrained, they can open a command shell by navigating to the windows directory.
Has anyone successfully talked profibus from a .NET application?
If you did, what device/card did you use to accomplish this, what was the application, and did you use any kind of preexisting or available code?
We've not used Profibus, but have used DeviceNET (another CAN based protocol), Ethernet/IP and ControlNet which all have similar challenges.
We've been doing this since the late 1990's and therefore rely mainly on our own generated code using off-the-shelf hardware. The companies that have shown longevity during that period that I remember are:-
AnyBus (HMS, www.anybus.com) we've recently started using their gateway products as we can place fieldbus interfaces close to the hardware and then communicate over normal Ethernet (usually using Ethernet/IP www.odva.org). This has the advantage of separating hardware and PC using only a network cable. The Ethernet/IP .NET classes were written by ourselves as nothing much was on the market at the time. I'm sure a quick google search would find suitable class libraries
SST (www.mysst.com) have had fieldbus interfaces for more than a decade. The last SST card we used for DeviceNET still only had VB6 sample code. A good selection of fieldbus support and different form-factors e.g. PC104, PCI, PMCIA
Beckhoff/Wago (www.beckhoff.com, www.wago.com) we typically use Beckhoff for the I/O more than the interface cards but again a company that has been around a long time. They also have products that support exposing using OPC (another way for you to get I/O information without directly communicating with the hardware/devicedrivers)
I suggest not using OPC interfaces to the hardware directly (it’s OK for communication using PC (.NET)->PLC->Profibus) as you need to ensure that the control system responds to loss of control from your .NET application. I’m assuming that you are needing a profibus Master here (not a slave), so as long as your control system is intrinsically fail safe, then loss of communication should mean the control system enters an "Idle" state and therefore most of the I/O will return to the fails safe state.
We also try to ensure that we do not put safety related code in .NET. Most of our .NET code is userinterface from a PLC, but in some places we do control the fieldbus directly but ensure hardware interlocks will prevent un-safe operation, either using safety switches/relays or a small PLC with the the task of interlocking only. And above all make the system fail-safe! Loss of comms from the .NET code should shutdown the automation to the fail-safe state.
We have used Steeplechase to connect to our profibus to our automated pick system.
http://www.phoenixcontact.com/automation/32131_31909.htm
Try this: http://libnodave.sourceforge.net