Paradise by the dashboard light.
For many years we have had the ability to expose Synergy data and logic through xfServerPlus which can be consumed, processed and displayed by cool Windows programs. But for me there has always been the “single thread” bottleneck. I’ve wanted my Windows applications to respond when the user drags the mouse, clicks a button, sorts a grid, at the time the event happens, and not when the program has caught up doing its background actions. Calling a remote method generally “hangs” the program until that operation has completed and this is because it’s being performed on the UI thread. And while the UI thread is busy calling into your xfServerPlus libraries and waiting for a response it blocks any user interaction so your application becomes unresponsive.
The answer is to utilize threads. Threads are separate processing channels that can run simultaneously. Your application always has at least one thread – the UI thread. But if you have a language that can allow multithreading then utilising this to perform background tasks on other threads frees your UI thread to continue being response to the user – its job really!
Welcome to Synergy.NET! Totally written in Synergy.NET and utilising the Symphony Framework I’ve written a fully functional interactive dashboard:
The user can fully define the record selection criteria and then issue the “Select” of the data. This selection is performed on a background thread. This means as the results are being returned from the remote Synergy DBMS file via xfServer the list is populated and the user can begin navigating the items within it. While the list is loading, the user can select an item even if the list load is not complete. At this point a number of background threads become active – each one loading data from different files via xfServer. The various lists are populated “in real time” and the application remains responsive – all the lists can be “loading” at the same time.
If the user clicks another item in the list the executing threads are instructed to “stop” and then the selection process restarts based on the newly selected master record.
Using the Symphony Framework and building my Synergy Repository based Data Objects using CodeGen I was able to quickly build the core components used in the Dashboard including the thread based selection code.
All this functionality is available in the latest V10.1 release of Synergy. To find out more details and to see multithreaded processing in action book your place at the upcoming DevPartner Conference at http://conference.synergex.com.
In: CodeGen, Development Tools, Events, Software Development, Success Stories, Symphony Framework
HTTP API Enhancements in DBL 10.1
In addition to introducing several totally new features DBL 10.1 also includes enhancements to the client portion of the HTTP API. These enhancements make the API significantly easier to use, and also make it possible to achieve things that were not previously possible.
Since the HTTP API was introduced in DBL 7.5 the client part of the API consisted of two routines. These routines are HTTP_CLIENT_GET and HTTP_CLIENT_POST. As suggested by their names these routines allowed you to issue GET and POST requests to an HTTP server. A GET request is a simple request to a server in which a URI is sent to the server and a response (which may include data) comes back. A POST request is slightly different in that in addition to the URI, additional data may also be sent to the server in the body of the HTTP request.
When dealing with an HTTP server it isn’t always possible to pre-determine the amount of data to be sent to the server, and it’s certainly not possible to know how much data will come back from the server for any given request. So in order to implement the HTTP API it was necessary to have a mechanism to deal with variable length data of any size, and at that time the only solution was to use dynamic memory.
Using dynamic memory worked fine, any data to be sent to the HTTP server as part of a POST request was placed into dynamic memory and the memory handle passed to the API, and any data returned from a GET or POST request was placed into dynamic memory by the API and the handle returned to the application. Dealing with variable length strings using dynamic memory isn’t particularly hard, but the fact of the matter is that while only a single line of code is required to perform an HTTP GET or POST, typically several lines of code were required in order to marshal data into and out of memory handles.
When the System.String class was introduced in DBL 9.1, so was the opportunity to simplify the use of the HTTP API, and that became a reality in DBL 10.1.
In order to maintain compatibility with existing code the HTTP_CLIENT_GET and HTTP_CLIENT_POST routines remain unchanged, but they are joined by two new siblings named HTTP_GET and HTTP_POST. These routines are similar to the original routines, essentially performing the same task, but they are easier to use because they use string objects instead of dynamic memory. And because the string class has a length property it is no longer necessary to pass separate parameters to indicate the length of the data being sent, or to determine the length of the data that was received. String objects are also used when passing and receiving HTTP headers.
So the new HTTP_GET and HTTP_POST routines make the HTTP API easier to use, but there is a second part to this story, so read on.
One of the primary use cases for the HTTP API is to implement code that interacts with Web Services, and in recent years a new flavor of Web Services called REST Services (REST stands for Representational State Transfer) has become popular. With traditional Web Services all requests were typically sent to the server via either an HTTP GET or POST request, but with REST Services two additional HTTP methods are typically used; the HTTP PUT and DELETE methods.
Many of you will be familiar with the term “CRUD” which stands for “Create, Read, Update and Delete”. Of course these are four operations that commonly occur in software applications. The code that we write often creates, reads, updates or deletes something. When designing traditional Web Services we would often indicate the type of operation via a parameter to a method, or perhaps even implement a separate method for each of these operations. With REST based web services however, the type of operation (create, read, update or delete) is indicated by the type of HTTP request used (PUT, GET, POST or DELETE).
To enable DBL developers to use the HTTP API to interact with REST services an extension to the HTTP API was required, and DBL 10.1 delivers that enhancement in the form of another two new routines capable of performing HTTP PUT and DELETE requests. As you can probably guess the names of these two new routines are HTTP_PUT and HTTP_DELETE. And of course, in order to make these new routines easy to use, they also use string parameters where variable length data is being passed or received.
You can find much more information about the HTTP API in the DBL Language Reference Manual, which of course you can also find on-line at http://docs.synergyde.com. In fact, if you’re feeling really adventurous you could try Googling something like “Synergy DBL HTTP_PUT”.
In: Development Tools · Tagged with: Synergy 10
Unit Testing with Synergy .NET
One of the “sexy” buzz words, or more accurately “buzz phrases” that is being banded around with increased frequency is “unit testing”. Put simply unit testing is the ability to implement specific tests of small “units” of an application (often down at the individual method level) and then automate those tests in a predictably repeatable way. The theory goes that if you are able to automate the testing of all of the individual building blocks of your application, ensuring that each of those components behaves as expected under various circumstances, testing what happens when you use those components as expected, and also when you use them in ways that they are not supposed to be used, then you stand a much better change of the application as a whole behaving as expected.
There are several popular unit testing frameworks available and in common use today, many of which integrate directly with common development tools such as Microsoft Visual Studio. In fact some versions of Visual Studio have an excellent unit testing framework build in; it’s called the Microsoft Unit Test Framework for Managed Code and it is included in the Visual Studio Premium and Ultimate editions. I am delighted to be able to tell you that in Synergy .NET version 10.1 we have added support for unit testing Synergy applications with that framework.
I’ve always been of the opinion that unit testing is a good idea, but it was never really something that I had ever set out to actually do. But that all changed in December, when I found that I had a few spare days on my hands. I decided to give it a try.
As many of you know I develop the CodeGen tool that is used by my team, as well as by an increasing number of customers. I decided to set about writing some unit tests for some areas of the code generator.
I was surprised by how easy it was to do, and by how quickly I was able to start to see some tangible results from the relatively minimal effort; I probably spent around two days developing around 700 individual unit tests for various parts of the CodeGen environment.
Now bear in mind that when I started this effort I wasn’t aware of any bugs. I wasn’t naive enough to think that my “baby” was bug free, but I was pretty sure there weren’t many bugs in the code, I pretty much thought that everything was “hunky dory”. Boy was I in for a surprise!
By developing these SIMPLE tests … call this routine, pass these parameters, expect to get this result type of stuff … I was able to identify (and fix) over 20 bugs! Now to be fair most of these bugs were in pretty remote areas of the code, in places that perhaps rarely get executed. After all there are lots of people using CodeGen every day … but a bug is a bug … the app would have fallen over for someone, somewhere, sometime, eventually. We all have those kind of bugs … right?
Anyway, suffice it to say that I’m now a unit testing convert. So much so in fact that I think that the next time I get to develop a new application I’m pretty sure that the first code that I’ll write after the specs are agreed will be the unit tests … BEFORE the actual application code is written!
Unit testing is a pretty big subject, and I’m really just scratching the surface at this point, so I’m not going to go into more detail just yet. So for now I’m just throwing this information out there as a little “teaser” … I’ll be talking more about unit testing with Synergy .NET at the DevPartner conferences a little later in the year, and I’ll certainly write some more in-depth articles on the subject for the BLOG also.
In: Development Tools · Tagged with: CodeGen, DevPartner Conference, Synergy 10
The changing face of data.
With the eagerly anticipated release of Synergy/DE version 10 we now have the ability to track and manage changes to Synergy DBMS data files. This new feature, Change Tracking, gives you the ability to track and monitor records within a file that have been modified, added or deleted.
Using the snapshot facility you can start a new snapshot within a file and begin your applications normal processing. Any file updates are records against the current snapshot. There can only ever be one active snapshot within a file so as soon as you start a new snapshot, all previous ones become an historical record of the changes made to the file. In code you can access any existing snapshot within a file to trace the activity using the new Select class.
A recent development for a customer required code changes to a number of programs. All the programs together defined a process and it was imperative that my changes didn’t break that process. I wanted to be able to test the changes to the data after running each program and not just when I’d run all the programs for the process. With Change Tracking this was a very easy task. I simply created a new snapshot across all my files before running each program. Using the Symphony Framework and CodeGen I created a simple program that displayed the records within a particular snapshot, so I could easily see what changes the program had made. If a program didn’t do what I had expected (I intentionally coded in a bug just to check this!) I could simply rollback the current transaction, fix the program and continue. I no longer have to restore the data and start my testing from the beginning.
You can see just how easy it is to utilise Change Tracking by watching a short video I’ve uploaded to YouTube. Enjoy!
There are many applications for Change Tracking, and at this year’s DevPartner conference I’ll be exploring this new feature in detail – including having attendees help me demonstrate many of the capabilities!
In: CodeGen, Development Tools, Events, Software Development, Symphony Framework
Making Maintenance Easy!
The Symphony Framework continues to develop and expand its capabilities. The latest version (2.0.0.1) has a number of extensions that allow you to build powerful single file/structure maintenance programs. These programs, known as CRUD style programs (http://en.wikipedia.org/wiki/Create,_read,_update_and_delete), allow the maintenance of data within the file.
Creating these “simple” programs can often be a time consuming process. You need to create the User Interface, showing what fields the user can see and amend. You’ll need a lookup as well, so the user can search for existing records. Your users will need the ability to add new records, and of course be able to remove records from the file.
This is where the Symphony Framework and CodeGen can “take the strain”. Today you can write a complete CRUD program, including a totally flexible query lookup mechanism without writing a single line of code!
The Symphony Framework is packed full of powerful templates that help you utilize CodeGen to generate all the components to build modern Windows Presentation Foundation based desktop CRUD applications in Synergy .NET. Templates include the ability to display and format the “key” and “data” views of a repository structure. These “views” are then used to build the user interface.
The lookup capabilities allow the user complete flexibility when they wish to search for existing records in the file. The criteria “view” is totally customisable by the user and they can select any fields, which you’ve allowed access to, within the structure to select matching records. The resulting list of matching records can again be fully tailored to meet the user’s requirements. Columns can be hidden or revealed as required and they can also be reordered and sorted. Selecting a record from the list allows you to amend the details, and then return you back to the populated query list.
The complete program provides a graphical menu and toolbar so the user can easily navigate the various CRUD options available. There are also “hint” icons that help the user to understand the capabilities the programs provide.
You can view a video that demonstrates these powerful new features of the Symphony Framework on YouTube by clicking this link: http://youtu.be/pByhm0fgi_k. Happy viewing!
In: CodeGen, Development Tools, Software Development, Symphony Framework
Keeping Focus
In a traditional Synergy application you have usually always had total control over the user interface. Your program code has displayed the field prompts on the screen, or loaded and placed your UI Toolkit windows. With the user interface defined and displayed it’s again your application code that controls what the user can do, and when. If they enter an invalid value in a field the code would usually display some sort of message and force the user back into the field, never to leave until a valid (according again to your application logic) value has been entered. And the UI Toolkit continues this tight coupling between field validation, user notification and UI navigation control.
As software development moved forward with Microsoft WinForms based applications this trend generally followed. The code behind each control knows everything about the control, and as such can force the focus back to the field when required.
With the advent of the Windows Presentation Foundation (WPF) application things changed dramatically. Of course you can still bind code-behind to your controls on your WPF forms, but that’s really not the point of WPF – if you have code behind then the chances are you are going something wrong. The most powerful feature of WPF is data binding. Data binding is the ability to bind an object property value to a field or control on your user interface. Messaging between the UI and the application ensure that your data is kept synchronised. This is the Model-View-View Model (MVVM) design approach, which is the cornerstone of a Symphony Framework based Synergy .NET WPF application. MVVM provides for a platform that fully (and correctly) disconnects the user interface from the application data and logic. But if the application has no knowledge of the UI, and the UI has no knowledge of the application logic, how can your programs force fields on your forms to have focus? There are many better ways to provide user feedback than to display modal messages and force the user back into the field entry, which I’ll discuss in a future blog. But there will always be someone who needs to be able to re-focus a field within the user interface from within their program. Code-behind will be required, yes? No, not if you use a Symphony Framework Data Object!
Symphony Framework provides the ability to request focus be given to whatever control you are using to bind against a particular Data Object property. And focusing that control is the responsibility of the View, or XAML code – there is no code-behind requirement. From within you application you can set a property in the Symphony Framework Data Object indicating that you would like the control associated with that data property to be given focus. In the XAML you listen for the request and honour it or not, at the discretion of the UI designer. And that request can bound to simple controls or complex containers.
Do you want to know how? Instead of writing up lots of code I’ve prepared a short video that demonstrates this powerful new feature of the Symphony Framework. You can view the video on YouTube by clicking this link: http://youtu.be/XpGzzBOo5mk. Happy viewing!
In: CodeGen, Development Tools, Software, Software Development, Symphony Framework
Symphony Framework and CodeGen Helping Customers Migrate to a WPF UI
Richard Morris and I have just returned from a seven-day consulting engagement with a customer, and I wanted to share with you some information about our achievements during the visit. The customer we visited with is one of our larger ISV’s and has an extensive Synergy application, much of which is implemented using the Synergy/DE UI Toolkit. As with many applications, life started out on cell-based systems many years ago, but for many years now it has been deployed exclusively on Windows systems.
The customer in question had listened to us talking about Symphony Framework and CodeGen at the Chicago DevPartner conference, and was interested in how they might be able to leverage them to accelerate the process of updating the look and feel of their applications by replacing their existing UI Toolkit user interface with a Windows Presentation Foundation (WPF) user interface. Needless to say we were eager to help, because we believe we have a great story to tell, and some great tools to share!
Most in the industry would agree that WPF represents the current “state of the art” when it comes to implementing user interfaces for Windows Desktop applications. We have had our eyes on WPF for some time now, and have been learning about it’s capabilities. We have also been encouraging customers to consider WPF as a great way of updating the UI of their existing applications, or implementing the UI of new applications. And thanks to new features in Synergy/DE 9.3 and 9.5 there are a couple of great ways of doing just that.
For existing applications the Synergy/DE .NET Assembly API can be used to embed WPF directly into existing applications. Of course one of the main benefits of doing so is that the application can be enhanced screen-by-screen, without the need for extensive re-writes and long development cycles. Of course for new development Synergy .NET can be used to build all-new applications with a WPF user interface. There is also a realistic migration path between the two; you can chose to start off by enhancing screens in an existing application via the .NET Assembly API today, and then ultimately migrate the entire application to a native Synergy .NET solution. All very “doable”.
Before I get into the specifics of our tools and what was achieved, there is one more thing that I should mention. Just as most industry pundits would agree that WPF is the way to go for Windows Desktop applications, most would also tell you that there is a specific WAY that WPF applications should be implemented; it’s called the “Model-View-ViewModel Design Pattern”, which is often abbreviated as MVVM.
A design pattern describes a methodology for implementing a software solution to a certain problem. The MVVM design pattern sets out a way of designing software such that there are clear lines of demarcation between code that deals with different parts of an application. Specifically it prescribes how the “Model” (code which implements an applications data definitions and business logic) should be separated from the “View” (code which implements the applications user interface), and how these two entities should be joined by the “ViewModel”. We’ve talked quite extensively about MVVM in the past, and there are lots of great resources available on line, so I don’t intend to go into more detail here. Suffice it to say that adhering to the MVVM design pattern is strongly recommended when implementing WPF applications.
I mentioned earlier that we have been focusing on WPF for some time now, and also on MVVM. But as well as just learning about the technologies and patterns, Richard Morris has been “beavering away” at his home office in England pondering the question “how can we help our customers to easily use WPF and MVVM in the context of their existing Synergy applications?”. Once he’d finished pondering the question, he then started coding the answer … and the Symphony Framework was born.
So just what is the Symphony Framework and how can it help you? Well in a nutshell, Symphony Framework is an MVVM Framework (library) which can be leveraged by Synergy developers to significantly simplify the process of implementing WPF user interfaces in their Synergy applications, while at the same time adhering to the best practices prescribed by the MVVM design pattern. Symphony Framework can be used to incrementally add WPF UI to existing applications in conjunction with the .NET Assembly API, and it can be used to implement all-new Synergy .NET applications with a WPF UI.
Some areas of Symphony Framework are designed to specifically address the somewhat unique challenges associated with migrating UI Toolkit applications, but the framework is in no way limited to working only with UI Toolkit applications. To cut a long story short, if you have an existing Synergy application and want to “spiff it up” with a fabulous new WPF UI, then Symphony Framework might just become your new best friend!
I’m not going to go into a huge amount of detail about HOW this all takes place, but I do want to briefly describe some of the common steps. For the purpose of this illustration I’ll ask you to imagine an existing UI Toolkit application (but remember, it doesn’t have to be Toolkit), and imagine that I want to do a gradual screen-by screen migration to a WPF UI, initially driven by the existing application (via the .NET assembly API). What might the steps be? Well, for each screen (or window) we might:
- Create a “Model” class that describes and exposes the underlying data to be worked with. Model classes inherit a lot of functionality from base classes in the Symphony Framework.
- Create a “View” using WPF.
- Create a “ViewModel” that exposes the information in the model to the view, and provides the functionality needed to service the requirements of the view. ViewModel classes also inherit a lot of functionality (in some cases all of the required functionality) from base classes in the Symphony framework.
The code for all of the steps described above would be implemented in Synergy .NET and would be compiled into a .NET assembly.
- Use the .NET assembly APIs “GENNET” tool to create Traditional Synergy “wrapper” classes that allow these various components to be accessed and manipulated from the existing Traditional Synergy application.
- Create a “Manager” class (we’re still trying to figure out what to call this bit!) which contains the bulk of the code required to instantiate and drive the underlying .NET code.
- Modify the existing application to present the new WPF UI instead of the existing UI, primarily by accessing functionality exposed by the “Manager” class.
You might be tempted to see this last bullet point and think “there is is, modify our existing code, that’s the hard and time consuming part”! But don’t let this thought put you off, believe it or not the changes that typically need to be made to the existing code are relatively small and painless. This is due in no small part to the things that the Symphony Framework is doing for you!
During our visit with our customer we initially worked on what it would take to replace existing “lookup” routines with new WPF implementations. In a UI Toolkit application a lookup routine is often accessed via a “drill method” associated with an input field, and often uses a combination of input processing to allow the user to define search criteria, and list processing to present matching results. When the user picks an item the associated value is returned into the input field. We managed to get this process down to a fine art. and this is where CodeGen comes in.
We were able to create CodeGen templates which allowed us to generate most of the code that was required to “switch out” a UI Toolkit lookup for a WPF lookup. We were able to code generate 100% of the Model class, 100% of the View class, 100% of the ViewModel class, and 100% of the “Manager” class. All that remained was to modify the existing application to utilize the new code instead of the existing UI Toolkit UI. Figuring out how to do the first lookup probably took in the order of half a day, but with the process and CodeGen templates in place, the next four lookups probably took around 20 minutes each to implement. We left it at that, because we were confident that we had the process down at that point.
Then we moved on to other areas, attacking a “maintenance” type program. The process is actually remarkably similar, and actually not that much more complex, again because much of the base functionality required is inherited from the Symphony Framework. By the end of our engagement we pretty much had that process down also, and again much of the required new code was being code generated, leaving only relatively minor changes to the existing application to be made.
Of course not all aspects of an application are as simple to deal with as the scenarios that I just described, some parts of an application and its UI get pretty complex, and it isn’t always possible to code generate all of the required components, and it isn’t always possible for the Symphony Framework to provide all of the required functionality in the form of base classes. Programmers still have a role to play, and thank goodness for that! But I do believe that the tools that Richard and I have developed can play a significant role in projects of this type, and it’s not just theory, we just proved it!
Actually that’s probably not a totally fair statement for me to make, as there are several other customers who have already used the Symphony Framework with great effect. Just as there are many customers who already use CodeGen to generate many different types of code to address various application needs. But Richard and I don’t often get to work together on a project, and this is perhaps the first time that we have really tried to use both of these tools together and push them HARD to see what could be achieved. And I for one am confident that everyone involved, including our customer of course, was pretty impressed with the results.
By the way, if your goal is to build an all-new WPF application directly in Synergy .NET, while retaining and re-using large portions of your existing code, then the steps aren’t that different to those described above. The Models, Views, ViewModels and “Manager” classes would be essentially the same, but would be driven by a Synergy .NET WPF application rather than by a DBR application via the .NET Assembly API. We actually proved this recently while preparing a proof of concept demo for another customer. Having been provided with the code for a small sample application, and some sample data, we migrated the UI of the application to WPF using the steps described above. Once the application was working with a new UI, and armed with the classes that we had just created, we were able to re-purpose those classes without change in a 100% Synergy .NET WPF application. In all the process took about four hours … but probably could have been completed faster had we not been sat at a bar at the time! This really is pretty cool stuff!
Before finish I do want to stress one more time that the Symphony Framework and CodeGen tools are not just about UI Toolkit applications on Windows. Symphony Framework helps you migrate to an ultra-modern WPF UI on Windows, but the starting point could easily be an application that runs on a cell-based platform today. And CodeGen can be and is being used on all systems supported by Synergy.
In: CodeGen, Success Stories, Symphony Framework · Tagged with: .NET Assembly API, CodeGen, Symphony Framework, Synergy.NET, Synergy/DE 9.5.3
Release Notifications for CodeGen and Symphony Framework
At the DevPartner conference I told people that in order to receive notifications for new releases of the open source CodeGen and Symphony Framework projects they should “Follow” the projects on CodePlex.
It turns out that “following” a project doesn’t send release notifications. If you want to get release notifications then you must go to the “Downloads” page for each project and subscribe for notifications. If you are interested in either of these two projects then I would recommend that you do just that, as we’ve done some great enhancements to both recently, and there are more great things still in the pipeline.
The downloads page for CodeGen is at http://codegen.codeplex.com/releases and the downloads page for Symphony Framework is at http://symphonyframework.codeplex.com/releases.
In: Development Tools · Tagged with: CodeGen, Symphony Framework
Are you Ready for Windows 8 and Synergy 10?
As discussed at the recent DevPartner Conferences, support for Synergy applications on Windows 8 will be introduced in Synergy 10, which is currently available as a beta release. Microsoft has announced the launch date for Windows 8 and Visual Studio 2012 will be October 26th, so it is reasonable to expect that the final versions of Windows 8 and Visual Studio 2012 will be available to developers via MSDN some time soon.
As well as introducing many new features and enhancements in Synergy .NET, Synergy 10 also includes some very significant new features on all of the Traditional Synergy platforms, particularly in the area of SDBMS (that’s ISAM to us mere mortals!). These changes are introduced in a new ISAM revision 6. It is important that you test your applications with Synergy 10 as soon as possible.
As soon as Windows 8 is available to your customers you are likely to start getting calls to install your applications on Windows 8, and that will REQUIRE you to install Synergy 10. At the very least, Synergex recommends that you install the Synergy 10 beta on a system (not necessarily Windows 8 ) and validate that your current application runs without errors. And if you don’t have s system to to that with, remember that it’s easy to build a Virtual Machine to use for testing.
Even better would be to rebuild your applications with version 10 and make sure you don’t have any issues there. And even better than that would be to do a little beta testing and try out some of the many cool new Synergy 10 features. There are even REWARDS for finding bugs!!!
You can find more information about Synergy 10 at http://www.synergyde.com/products/synergyde_beta.aspx
In: Software Development · Tagged with: Synergy 10, Windows 8
Beauty and the Beast
With every advancing version of Synergy/DE we are better armed to tame the beast! For me one of the biggest beasts in a commercial application is a record lock. This beast will appear without warning, leave no trace of its being, and always instils rage in the innocent users of the system who encounter it.
Although locking records is a fundamental requirement of any application it is always difficult to explain to a user who has been sat there for ten minutes with a “record locked” message flashing on the screen that “the system is functioning correctly”. All they want to do is move forward and finish the task in hand.
So who has that rouge record locked? Which line of code is actually causing the lock? Is the lock valid? How long has the lock been there? If we could answer these questions then life would be so much easier. So how can we tame the record lock beast? With Synergy 9.5.3b of course!
If you attended the DevPartner conference in either Chicago or York then you would have seen my presentation “Hooked Line & Sinker”. During the session I presented the new (and extremely cool) IO Hooks class that allows you to hook methods to the various events that occur around SDBMS data access. For example you can register methods that are executed every time a record is read, stored, updated or deleted. And given this capability I demonstrated the beautiful Synergy DBMS Lock Viewer. By assigning my LockRecorder class to every file opened in update mode (a single line code change to my standard file open routine) I was able to record lock information in a central “lock manager” control file. The Synergy DBMS Lock Viewer program I wrote then reads this file and displays lock information.
And the real beauty was just today. Having modified a customer’s application to utilise the LockRecorder class I was able to run the Lock Viewer:
And immediately identify who was locking which records in which programs and how long the locks had been there. It’s beautiful to just sit and watch the lock information appear and then clear – and when they don’t clear we call the culpritJ. The usual response was “I just nipped out to get a cuppa”. Maybe not the users fault, but now I know where to look in the program to see if I can prevent the lock being required.
If you are interested in the example code you can use the “Knock Knock Who’s Locked” tutorial which steps you through the whole process of creating the LockRecorder class and monitoring the lock manager control file. The tutorial, along with all conference tutorials, can be downloaded from http://tutorials.synergex.com/.
In: Software Development, Success Stories
Subscribe to the Synergy/DE PSG Blog
