- Delphi Debugger Blue Dot But Red With Cross Symbol
- Delphi Debbuger Blue Dot But Red With Crossed
- Delphi Debbuger Blue Dot But Red With Crossover
I’ve been working to build a deliverable package in HANA (UI5 application and supporting back-end) to send out to customers. And part of the development process, as many readers will know, is debugging stored procedures. In some cases, you’re awesome, and you don’t need to do this – “I know it works, I wrote it”. But sometimes, just sometimes, it’s helpful to turn to the debugger to see why a particular piece of functionality is not working as expected. But what to do when you don’t have the auths to debug your own stored procedure?! Eeeeep!
On Fri, 19 Dec 2014 02:16:19 -0800, Carl-Henrik Nilsson wrote: What in the world could be causing this strange behaviour? And how can I enable debugging? 2011: Delphi FireMonkey (full cross-platform capabilities) 2019: Delphi now is at version 21 and keep counting. Until today Delphi had 30 major releases or 40 if you count Turbo Pascal. Each release has multiple subversions (updates). C Builder: 25 releases. There are 15 current Pascal compilers and 7 Pascal dialects out there. (This is a standard test that must be tried for every property that can hold a pointer to an object on the form.) However, since this is a design time failure, there are no useful debug tools (that I know of) that simplify problem identification. Delphi’s debugger uses DebugHook to determine what to do with exceptions. When an application runs normally, DebugHook is 0. When you debug an application in Delphi’s IDE, the IDE sets DebugHook to 1. When the IDE catches an exception or when you are single-stepping in the debugger, the IDE sets DebugHook to 2.
To set the scene, I’m writing a UI5 app, with an OData HANA-only (i.e. no Gateway here) back-end, and have in place a number of OData modification exits. The modification exits are mostly stored procedures (.hdbprocedure files). Read up on these over here: Custom Exits for OData Write Requests – SAP HANA Developer Guide for SAP HANA Studio – SAP Library
I’ve got an update modification exit on one of my OData entities, Forecasts.
service {
“fa.apps.hpc.xs.views.forecasts::forecasts_by_user_view” as “Forecasts” key (“id”)
navigates(
“ForecastFields” as “Fields”,
“ForecastDataSet” as “DataSet”,
“ForecastRuns” as “Runs”
)
create using “fa.apps.hpc.xs.procedures.forecast::createForecast”
delete using “fa.apps.hpc.xs.procedures.forecast::delimitForecast”
update using “fa.apps.hpc.xs.procedures.forecast::updateForecast”;
}
That’d be this guy, in bold. If you’re savvy, an update modification exit stored procedure needs a particular signature.
PROCEDURE “FA_APPS”.”fa.apps.hpc.xs.procedures.forecast::updateForecast” (
IN new <TABLE_DEFN>,
IN old <TABLE_DEFN>,
OUT outtab <HTTP_ERRORS DEFN>
)
LANGUAGE SQLSCRIPT
SQL SECURITY INVOKER
— DEFAULT SCHEMA <SCHEMA>
AS
— READS SQL DATA AS
BEGIN
— Weave your update magic here
END;
I wanted to debug it, just for fun (actually, for a very real reason). The trouble I found however, is that because this stored procedure exists in another schema to my user’s one, debugging is no longer automatically available. In Eclipse (I use Eclipse with HANA Add-ons, not HANA Studio, although effectively the same thing) you’ll still be able to set the breakpoint, as per below. Nice blue dot. Perfect! Break point set.
But when you start debugging said procedure, you’ll notice a little cross over your breakpoint.
Nooooooooooooooooooo!!!!!!!!
That didn’t happen before when the stored proc belonged to my schema. But of course, that was my schema. My user owns it and everything in it, including debug privileges for all stored procedures. So I messed around a bit, not quiet grasping what was required here. I also followed the inimitable Rich Heilman’s instructions, which you can peruse over here:Unable to Debug a activated Procedure in HANA XS environment. but they didn’t quite do what I needed. Presumably, I already had sufficient auths in HANA to debug a procedure, but I didn’t have auths to debug this procedure. So I persevered. As you do. And keep doing. And keep on doing… until eventually it clicked! Hunting though the Object Privileges I could apply to my user, low and behold, I see my stored procedure in the list:
“Hmmmmm” I think to myself. “I wonder what will happen if I…”
And there you have it. Once you add the stored proc to your user under Object Privileges, you then determine what specific privileges you should have (note: I’m logged in here as a user with user admin auths, so I can grant privileges to my user, but you could just as well use SYSTEM or whatever if this is not an important HANA instance).
So that’s lovely to know. I can add stored proc auths directly to my user. But this is going to be a deliverable package/app. It follows that I should define such auths in an HDB Role artifact – heck, I’m doing that already for all other components of this app, so best keep on point. So, for the purposes of this post, I’ll demonstrate adding this to my existing HDB Role artifact. Were you to do this productively, you might consider creating a separate .hdbrole file for debug/administration of the app. I’ll keep everything all together for now. I should note, that I am not saving my user with the privileges above. I don’t want to have to apply individual privs to each and every user – I already have an .hdbrole file, so I’ll use that. Please also note that, shortly after writing this post, I found Rich’s post on pretty much exactly this topic. New SQLScript Features in SAP HANA 1.0 SPS7 – specifically, the last section Debugging Authorisation Concept. I’ve basically just expounded on what’s covered in this post, and the one I linked to earlier.
Right then, to my HDB Role! Now, this role is already applied to my user. So any changes to it should automatically apply to my user too.
role fa.apps.hpc.xs.roles::USER_ROLE {
// This is a very broad smattering of privileges for a schema, and will be paired back once the supporting
// stored procedures are in place.
schema fa.apps.resources:FA_APPS.hdbschema: SELECT, INSERT, UPDATE, DELETE, EXECUTE, DEBUG;
// Lots of guff here
// Here’s the stored procedure declaration with the required privileges – EXECUTE and DEBUG
catalog sql object “FA_APPS”.”fa.apps.hpc.xs.procedures.forecast::updateForecast” : EXECUTE, DEBUG;
// Lots of guff here
}
Add our procedure privileges as above (including DEBUG on the schema), activate the role, restart debugging of the procedure and…
Et voila. Our red cross has happily transformed into a green tick and we’re off debugging! I don’t know about you, but there’s a special, warm place in my heart reserved for green ticks.
#happysigh
In the debugger…
We are breaking exactly out our breakpoint now. Excellent.
This is just a smattering of information about the gauntlet that can be HANA auths. The thing is, they’re not really complicated. But it can be hard sometimes to figure out what’s required. As this post ironically proves.
For completeness:
My instance is HANA Developer Edition, hosted in AWS via. CAL, ver 1.00.091 (SPS9)
Eclipse is Mars running latest HANA and UI5 Add-ons
Credit for both references to Rich Heilman
Delphi - Component Debug
Now what?
This page contains a few of the more difficult design problems that I have had to work through. I hope it helps.
Delphi Debugger Blue Dot But Red With Cross Symbol
Constructor Missing 'inherited'
T_xyz = class(TComponent) public constructor Create(AOwner: TComponent); override; end; constructor T_xyz.Create(AOwner: TComponent); begin inherited; // the problem was caused by forgetting this // additional code here end; |
Using the following code, I was able to verify that when the program started, an object of type T_xyz was created (verified by setting a breakpoint in the constructor), yet the variable xyz1 was not assigned a value (was equal to 
nil - verified by setting a breakpoint) when FormCreate was called. Adding inherited to the constructor fixed the problem. type TForm1 = class(TForm) xyz1: T_xyz; abc1: T_abc; private { Private declarations } public { Public declarations } end; implementation procedure TForm1.FormCreate(Sender: TObject); begin abc1.xyz := xyz1; // xyz1 = nil when inherited was forgotten end; |
Wrong *Package* Name
The basic (and wrong) procedure is
- Create a new package
- Compile
- Install
This produces a default package name of
- C:Program FilesBorlandDelphi5ProjectsPackage1.dcu
C:Program FilesBorlandDelphi5ProjectsBplPackage1.dcp
C:Program FilesBorlandDelphi5ProjectsBplPackage1.bpl
At this point you can select your new components from the tool bar and place them on a form. If you want to change the code,
- Just recompile the package
- The form will be automatically closed
- Reopen the form (press F12) and the new properties (and whatever) will be displayed
OK, so now you save the package and give it a proper name. (Wow, are you screwed!!)
That's right, the old package is still there! You can write, compile, change whatever you want, and nothing is going to get fixed.
After 2 days of debugging a (very serious) problem, I decided to try and click Install again. That's when I saw the error
| Cannot load package 'dcl_mcXYZ_50.' It contains unit 'mcABC,';which is also contained in package 'Package1' |
Of course, the solution was simple
- Unload the bad package
- Load the correctly named package
- Previously, each time I compiled the package, the form would close .. because it contained components from that package. However, on the next day, clicking compile did not force the form to close.
Correct Procedure
- Create a new package
- Add the *.pas files
- Save the package (*.dpk file)
- Compile
- Install
Delphi Debbuger Blue Dot But Red With Crossed
My problem was that I installed the package before saving (and therefore - naming) it. As a result, the package was originally installed using a default name and all source code changes made after the save were ignored.More
| (Access violation at address 40003CAE in module 'Vcl50.bpl'. Read of address 000000EC) |
However, since this is a design time failure, there are no useful debug tools (that I know of) that simplify problem identification. As a result, I slugged through the source code trying to see what was wrong. In desperation, I tried to reinstall the package .. and found the problem.
Deleting the old Package
- From the menu, select
- Component / Install Packages...
- Open the new (properly named) package in Delphi. From the toolbar, select the Options icon and click on the Packages tab
In this case, I selected
- C:Program FilesBorlandDelphi5ProjectsBplPackage1.bpl
When I installed the new (properly named) package, the icons were restored and the design time error was fixed. In the final analysis,
- The error was because I forget to include inherited in the constructor
- And could not be fixed because I installed the package before I saved it with a proper name
Comments are closed.