I am trying to get to know the pgAdmin debugger and am fairly new to PostgreSQL. I don't know if the behavior I'm seeing is because of a mistake I am making or simply because of limitations in the debugger.
At the top of my function I've declared two variables:
declare tuple record;
declare buffer text;
In the body of my function I am trying to iterate the rows in temporary table TT_CALENDAR, so it would be possible to examine the contents of the temporary table in the Locals window:
for tuple in
select startdate, enddate from TT_CALENDAR
loop
buffer := concat(buffer, tuple.startdate::text, tuple.enddate::text,'|');
end loop;
buffer :='';
Breakpoints are set at buffer := concat(... and at the line buffer :=''; and program execution stops there as expected, but as soon as we exit the loop and arrive at buffer :=''; the string value vanishes from the Locals window.
Why would buffer's displayed value vanish from the Locals window when we exit the loop before buffer :=''; is executed? It's as if the variable has gone out of scope.
P.S. Is there a configuration setting that would cause long values to wrap in the Locals window Value cell?
Thank you
This really sounds like a bug with the debugger. I would generally recommend following up on the pgadmin email lists and alert the developers to this problem.
There is no reason I know that the variables would be out of scope so it sounds to me like it is a bug in the debugger itself.
Related
I have the following before-insert trigger, that assigns a sequence number to a record of an intersection table:
before insert on psln
for each row
declare v_seqnr number;
begin
select nvl(max(psln_seqnr),0) into v_seqnr from psln where pers_id = :new.pers_id;
:new.psln_seqnr := v_seqnr + 1;
end;
Now i want to debug this trigger to see if v_seqnr gets the proper value, depending on the value of :new.pers_id. These are the steps i take:
i configure the Start Debugging Option (Tools - Preferences - Debugger) as follows:
(when i choose a different option, my stack window remains empty while debugging, see below)
i compile the trigger for debugging (Ctrl-Shift-F8)
i place a breakpoint on the begin-statement
i start debugging the trigger (Ctrl-Shift-F10) and get the following debug popup window, where i enter the values 1,1 for the insert-statement, that will cause the trigger to fire:
i press OK and see the following (note the green V on the red breakpoint, which i think is the point of execution):
when i now click on the Step-Into debug-icon with the red arrow (or press F7), i expect to jump to the first line of code in the begin-block, but nothing happens ...
i also expect to see the value 1, when holding my mouse over the :new.pers_id expression, but this also does not work
Can someone please explain me what i am doing wrong or what i have forgotten?
I think this is a known bug, in SQLDEVELOPER, one fix for it, could be instead of use an ANNONIMOUS PROCEDURE (which is created when you type in the "lady bug"), you can try to fire the trigger by a normal STORE PROCEDURE, that means, you can create a "dummy", procedure which emulates the insert, compile it for debug, an run it, if all work well, your execution should stops in the trigger's break point, is like to do a simulation of debug a procedure which has a trigger in.
I have a problem here while exporting data from oracle database to CSV file using a procedure. While exporting data, sometimes the CSV file is getting truncated and the error it shows is "ORA-29285 - File write error". The problem here is the file is getting truncated not all the times but randomly.
Edit : Below is the chunk of code I used in my procedure
conn := utl_file.fopen('sample_directory','output.csv','W',4096);
for i in (select * from per_data)
loop
utl_file.put_line(conn,i.name||','||i.sub||','||to_char(i.start_date,'dd-mon-yy')||','||to_char(i.expire_date,'dd-mon-yy')||','||i.loc||CHR(13));
end loop;
utl_file.fclose(conn);`
I am pulling my hair to trace out the reason. Can someone help me out ?
One way to get this error is to open the file with a certain maximum line size - possibly the default 1024 - and then try to write a single line to that file which is longer than that.
In your case you don't seem to be doing that, as you open it with 4096 and your lines are all (apparently) shorter than that.
So you may be hitting the 32k limitation:
The maximum size of the buffer parameter is 32767 bytes unless you specify a smaller size in FOPEN. If unspecified, Oracle supplies a default value of 1024. The sum of all sequential PUT calls cannot exceed 32767 without intermediate buffer flushes.
You don't seem to be doing any flushing. You could change your put_line call to auto-flush:
utl_file.put_line(conn,
i.name||','||i.sub||','||to_char(i.start_date,'dd-mon-yy')
||','||to_char(i.expire_date,'dd-mon-yy')||','||i.loc||CHR(13),
true);
or keep a counter in your loop and manually flush every 100 lines (or whatever number works and is efficient for you).
As noted in the documentation:
If there is buffered data yet to be written when FCLOSE runs, you may receive WRITE_ERROR when closing a file.
You aren't flushing before you close, so adding an explicit flush - even if you have autoflush set to true - might also help avoid this, at least if the exception is being thrown by the fclose() call rather than by put_line():
...
end loop;
utl_file.fflush(conn);
utl_file.fclose(conn);
I'm using the vcl.printers unit (delphi XE8) and I'm facing an error when "talking" to a printer.
I traced into the vcl.printers and found this code (written by EMB people):
if OpenPrinter(ADevice, FPrinterHandle, nil) then
begin
if DeviceMode = 0 then // alloc new device mode block if one was not passed in
begin
DeviceMode := GlobalAlloc(GHND,
DocumentProperties(0, FPrinterHandle, ADevice, nil, nil, 0));
if DeviceMode <> 0 then
begin
DevMode := GlobalLock(DeviceMode);
if DocumentProperties(0, FPrinterHandle, ADevice, DevMode^,
DevMode^, DM_OUT_BUFFER) < 0 then
begin
GlobalUnlock(DeviceMode);
GlobalFree(DeviceMode);
DeviceMode := 0;
DevMode := nil;
end
end;
end;
if DeviceMode <> 0 then
SetPrinterCapabilities(DevMode^.dmFields);
end;
The
DocumentProperties(0, FPrinterHandle, ADevice, nil, nil, 0)
return the correct buffer size the first time (I haven't written it somewhere), then going thru the second execution time it returns 4294967295 bytes, indeed a -1 because declaration is wrong, but meanning an error.
As you can see the VCL code handle the errors very poorly since there is no error check !
But what error I have here and why ?
DocumentProperties lies in winspool.dll
To recover from it, I need to reboot the PC, but I cannot use this more than one time pass that is vey annoying for debug.
The printer is simply the "PDFcreator"
I tried with other PC and seems OK even if I run it many times.
I have also two laser network printers.
Thanks
In the past I did have the same problem with two customers. I did track it down to printers unit (printers.pas) Kind of hard to track it down without debugger on a distant computer in other part of my country.
Ok.. but I did track it all the way down to this line:
DeviceMode := GlobalAlloc(GHND, DocumentProperties (0, FPrinterHandle, ADevice, StubDevMode, StubDevMode, 0)); in the function SetPrinter in the unit PRINTERS.PAS
When I did broke it up into two lines, i.e. call to DocumentProperties first and store the value in integer variable and then check the value and only then call Globalalloc if the value is greater than 0 and kind of debugged it with stored values in debug file the error was truly in the DocumentProperties function from SPOOL.DLL if I remember correctly. This function returned -1 as size for the device, but only with this customer on one computer (he is using 4 or 5 with my program)
Of all my customers (close to 200 clients) I have had this issue on two computers. The other one fixed it kind of itself.. I didn't know how it did get fixed. The later one I was trying to fix just a couple of minutes ago. In the end I found a solution. I did fix this customer with simple change of shortcut. I began to use the automatic fix for compatibility in Windows 10 and then ran the button "test program" and it worked.. No error choosing printers or using it's propertis. Ok.. Then I tried again with the shortcut alone.. aarrgg.. error returned.. but then, aha.. I thought to myself "this has to connects to how Windows is running this program" and changed how Windows 10 ran the program as check "run as administrator" to uncheck.
And no problem.
On almost every compture with Windows 10 I do check "Run as Administrator" with no problems. I think there was a update or some issues with spool.dll that connects these dots.
ps. If you google this behavior with Delphi DocumentProperties problems, then you will find out this is known problem.. some say connected to x86 and x64 mode, but I found this out.
I have a Delphi 6 application that sends bitmaps to a DirectShow DLL in real-time, 25 frames a second. The DirectShow DLL is my code too and is also written in Delphi 6 using the DSPACK DirectShow component suite. I have a simple block of code that goes through each pixel in the bitmap modifying the brightness and contrast of the image, if a certain flag is set, otherwise the bitmap is pushed out the DirectShow DLL unmodified (push source video filter). The code used to be in the main application and then I just moved it into the DirectShow DLL. When it was in the main application it ran fine. I could see the changes in the bitmap as expected. However, now that the code resides in the DirectShow DLL it has the following problems:
When the code block below is active the DirectShow DLL is really slow. I have a quad core i5 and it's really slow. I can also see a big spike in the CPU consumption. In contrast, the very same code running in the main application ran fine on an old single core P4. It did hit the CPU noticeably on that old machine but the video was smooth and there were no problems. The images are only 352 x 288 pixels in size.
I don't see the expected changes to the visible bitmap. I can trace the code in the DirectShow DLL and see the numerical values of each pixel properly altered by the code, but the viewable image in the Graph Edit ActiveMovie window looks completely unchanged.
If I deactivate the code, which I can do in real-time, the ActiveMovie window shows video that is as smooth as glass, perfectly rendered with the CPU barely touched. If I reactivate the code the video is now really choppy, probably showing only 1 to 2 frames a second with a long delay before the first frame is shown, and the CPU spikes. Not completely, but a lot more than I would expect.
I tried compiling the DirectShow DLL with everything on including range checking, overflow checking, etc. and there were no warnings or errors during run-time. I then tried compiling for fastest speed and it still had the exact same problems listed above. Something is really wrong and I can't figure out what. Note, I do indeed lock the canvas before modifying the bitmap and unlock it after I'm done. If it weren't for the "everything on" compilation run I noted above I'd say it felt like an FPU Exception was being raised and silently swallowed with every pixel computation, but as I said, no errors or Exceptions are occurring.
UPDATE: I am putting this here so that the solution, which is embedded in one of Roman R's comment, is plainly visible. The problem that I was not setting the PixelFormat property to pf24Bit before accessing the ScanLine property. As Roman suggested, not doing this must make the TBitmap code create a temporary copy of the bitmap. As soon as I added the line of code below the problems went away, both that of changes not being visible and the soft page faults. It's an insidious problem because the only object that is affected is the pointer you use to access the ScanLine property, since (assumption) it contains a pointer to a temporary copy of the bitmap. That's must be why the subsequent TextOut() call still worked since it worked on the original copy of the bitmap.
clip.PixelFormat := pf24bit; // The missing code line that fixes the problem.
Here's the code block I've been referring to:
function IntToByte(i: Integer): Byte;
begin
if i > 255 then
Result := 255
else if i < 0 then
Result := 0
else
Result := i;
end;
// ---------------------------------------------------------------
procedure brightnessTurboBoost(var clip: TBitmap; rangeExpansionPowerOf2: integer; shiftValue: Byte);
var
p0: PByte;
x,y: Integer;
begin
if (rangeExpansionPowerOf2 = 0) and (shiftValue = 0) then
exit; // These parameter settings will not change the pixel values.
for y := 0 to clip.Height-1 do
begin
p0 := clip.scanline[y];
// Can't just do the whole buffer as a big block of bytes since the
// individual scan lines may be padded for CPU alignment.
for x := 0 to (clip.Width - 1) * 3 do
begin
if rangeExpansionPowerOf2 >= 1 then
p0^ := IntToByte((p0^ shl rangeExpansionPowerOf2) + shiftValue)
else
p0^ := IntToByte(p0^ + shiftValue);
Inc(p0);
end;
end;
end;
There are a few things to say about this code snippet.
First of all, you are using Scanline property of TBitmap class. I have not been dealign with Delphi for many years, so I might be wrong about this but I am under impression that Scanline is not actually a thin accessor, is it? It might be internally hiding things which can dramatically affect performance, such as "if he wants to access the bits of the image, then we have to first convert it to DIB before returning pointers". So a thing looking so simple might appear to be a killer.
"if rangeExpansionPowerOf2 >= 1 then" in the inner loop body? You don't really want to compare this all the way. Either make two separate functions or duplicate the whole loop without in two version for zero and non-zero rangeExpansionPowerOf2 and do this if only once.
"for ... to (clip.Width - 1) * 3 do" I am not really sure that Delphi optimizes the upper boundary evaluation to make it only once. You might be doing those multiplication thrice for every pixel, while you could do it only once the whole image.
For top perofrmance IntToByte is definitely implemented in MMX to avoid ifs and process multiple bytes at once.
Still as you say that images are only 352x288, I would suspect that #1 is ruining the performance.
I have an Oracle project that would be a good fit for using GUIDs as a key. I found the following snippet
SET SERVEROUTPUT ON
BEGIN
FOR indx IN 1 .. 5
LOOP
DBMS_OUTPUT.put_line ( SYS_GUID );
END LOOP;
END;
/
From http://feuerthoughts.blogspot.com/2006/02/watch-out-for-sequential-oracle-guids.html
When I run it against my database (I tried it on versions 10g and version 11) I get output like
64FE4083D6BA7CB4E0400F0A0E0A18B0
64FE4083D6BB7CB4E0400F0A0E0A18B0
64FE4083D6BC7CB4E0400F0A0E0A18B0
64FE4083D6BD7CB4E0400F0A0E0A18B0
64FE4083D6BE7CB4E0400F0A0E0A18B0
I.e. the value never changes! Is there something I have to do to set this up to work as expected?
Edit: I am not very observant - the GUIDs are changing, but it looks like I am suffering from the sequential GUID problem that the link above is talking about.
The value does change....
*
64FE4083D6BA7CB4E0400F0A0E0A18B0
64FE4083D6BB7CB4E0400F0A0E0A18B0
64FE4083D6BC7CB4E0400F0A0E0A18B0
64FE4083D6BD7CB4E0400F0A0E0A18B0
64FE4083D6BE7CB4E0400F0A0E0A18B0
*
Seems OK. From the description:
SYS_GUID generates and returns a
globally unique identifier (RAW value)
made up of 16 bytes. On most
platforms, the generated identifier
consists of a host identifier, a
process or thread identifier of the
process or thread invoking the
function, and a nonrepeating value
(sequence of bytes) for that process
or thread.
From your example:
64FE4083D6BA7CB4E0400F0A0E0A18B0
64FE4083D6BB7CB4E0400F0A0E0A18B0
64FE4083D6BC7CB4E0400F0A0E0A18B0
64FE4083D6BD7CB4E0400F0A0E0A18B0
64FE4083D6BE7CB4E0400F0A0E0A18B0
Nobody mentioned anything about the distribution of these GUID values. They should be nonrepeating and they are. Unless you get exactly the same output every time.