US prison contractor website is hacked

US website "Prison Contractor" is hacked. It is declared in  an anti-police campaign that anonymous hacker group have done this thing. One sub group "Antisec" took the responsibility of replacing the GEO GROUP website home page with a rap song dedicated to the murderer Mumia Abu Jamal.Mumia Abu is a former radio journalist serving a life sentence for the 1981 shooting death of a police officer.Hacker group left a message on a website home page that as part of our ongoing efforts to dismantle the prison industrial complex, we attacked one of the largest private prison corporations in the US - Geo Group.The hackers claimed to have gotten the addresses of more than 1,000 officers along with information from police warrants and court summonses as well as about informants in their weeks-long series of attacks on police computers. 

SQL query extension

By default, the standard program reads the entire main table when retrieving data for a particular form, even though some records and fields may not be required. By default also, the standard program reads only those reference table fields that are included on the form, even though the UI script and/or the DAL script may require other reference table fields. 

Query extensions define conditions that the standard program adds to the SELECT, FROM, and WHERE clauses of a database query in order to filter out unwanted records and fields of the main table and in order to include in the query all reference fields required by the form, UI script, and DAL script.
In the UI script, you program query extensions to minimize the number of records and fields of the main table read by the query and to retrieve any reference tables field that are required by the UI script but are not on the form. In the DAL script, you program query extensions to retrieve reference table fields that are required by the DAL script. 

When the standard program executes a database query, it automatically adds the query extensions defined in UI and DAL scripts. So, in the case of main table fields, the standard program reads only those fields and records that meet the conditions set in the query extension in the UI script. In the case of reference tables, the standard program reads those fields included on the main table and also those mentioned in the UI and DAL scripts.

Related Post:

4GL Main table section

You use main table i/o sections to program actions that you want to be executed when read or write actions occur on the main table. These sections are not relevant to type 4 programs, as such programs do not have a main table. Main table i/o sections consist of a main section and a subsection. The main section is always main.table.io. The subsection indicates when the actions must be executed. 


Note that main.table.io sections (except the read.view subsection) are ignored when the corresponding DAL hooks are programmed in a DAL script.


Main section
main.table.io:
The subsections associated with this main section are executed either before or after input to or output from the main table. The main table for the current session is defined in the data dictionary. 


Subsections
before.read:
The actions programmed in this subsection are executed immediately before each read action on the main table.


after.read:
The actions programmed in this subsection are executed after each read action on the main table. You can use this subsection to call skip.io() in order to skip the record just read and to read the next record (if necessary). 


before.write:
The actions programmed in this subsection are executed before each write action on the main table. A write action occurs when a record is inserted. You can use this subsection to call skip.io() in order to undo the write action. 


after.write:
The actions programmed in this subsection are executed after each write action on the main table. A write action occurs when a record is inserted. You can use this subsection, for example, to write data to tables other than the main table. 


after.skip.write:
The actions programmed in this subsection are executed if a write action on the main table has been skipped as a result of actions programmed in the before.write subsection. The actions are executed immediately after the skip action. 


before.rewrite:
The actions programmed in this subsection are executed immediately before each rewrite of a record in the main table. A rewrite action occurs when a record is changed. You can use this subsection to call skip.io() in order to skip the rewrite action. 


after.rewrite:
The actions programmed in this subsection are executed after each rewrite action on the main table. A rewrite action occurs when a record is changed. 


after.skip.rewrite:
The actions programmed in this subsection are executed if a rewrite action on the main table has been skipped as a result of actions programmed in the before.rewrite subsection. The actions are executed immediately after the skip action. 


before.delete:
The actions programmed in this subsection are executed immediately before each delete action on the main table. You can use this section to call skip.io() in order to skip the delete action. 


after.delete:
The actions programmed in this subsection are executed immediately after each delete action on the main table. You can use this subsection, for example, for deleting references, if this is not done automatically. 


after.skip.delete:
The actions programmed in this subsection are executed if a delete action on the main table has been skipped as a result of actions programmed in the before.delete subsection. The actions are executed immediately after the skip action. 


read.view:
The actions programmed in this subsection are executed immediately after a view action on the main table (start.set, first.view, next.view, prev.view or last.view). You can use this subsection to call skip.io() in order to skip an entire set of records with the same value in the view fields.


Example
main.table.io:
before.delete:
if (not pctst099.del) then
skip.io("pctsts0001")
| cannot be deleted
endif
read.view:
if strip$(pctst099.cprj) = "" then
skip.io("")


endif


Related Post:

4GL zoom.from Section

You use zoom.from sections to program actions that you want to be executed when the current session is activated as a zoom process. A zoom process can be activated by a form-specific command of type session, by zooming on an input field, by pressing CTRL+B, or by calling zoom.to$() in the program script. Zoom.from sections consist of a main section and a subsection. The main section specifies the process for which the actions must be executed. The subsections specify when the actions must be executed.


Main sections
zoom.from.<zoom name>:
Each field has a name that can be used as a zoom name. You can specify the zoom name in this main section. The zoom name indicates which field the current session was zoomed from (when the subprocess is started from a form command, the zoom name is "choice"). The subsections associated with this main section are executed when the current process was zoomed to from the specified process. 


zoom.from.all:
The subsections associated with this main section are executed for all processes from which the current session can be zoomed to. 


zoom.from.other:
A subsection associated with this section is executed for all processes for which the particular subsection has not been programmed in a zoom.from.<zoom name> section.


Subsections
on.entry:
The actions programmed in this subsection are executed each time the current process is started from the specified process(es). You can use this subsection to import variables. 


on.exit:
The actions programmed in this subsection are executed at the end of the current process, if the current process was started from the process(es) specified in the main section. You can use this subsection to export variables.


Example:
zoom.from.all:
on.entry:
import("globvar", localvar)
on.exit:
export("globvar", localvar)


Related Post:

4GL Field Section

You use field sections to program actions that you want to be executed for a variety of field events. Field sections consist of a main section and a subsection. The main section specifies the field(s) for which the actions must be executed. The subsections specify when the actions must be executed.


Main sections
field.<field name>:
The subsections associated with this main section are executed for the specified field. The field name you specify must correspond with the name on the form. 


field.all:
The subsections associated with this main section are executed for all fields on the form


field.other:
A subsection associated with this section is executed for all fields for which the particular subsection has not been programmed in a field.<field name> section.


Subsections
init.field:
The actions programmed in this subsection are executed the first time that the form on which the field occurs becomes current. The subsection is executed immediately before the init.form section of the form. You can use this section to change field attributes.


before.field:
The actions programmed in this subsection are executed each time the focus moves to the specified field. The subsection is executed immediately before the before.input or before.display subsections. 


before.input:
The actions programmed in this subsection are executed immediately before input to an input field commences. This section is supported for backward compatibility only. In BaanERP programs, use enable.fields() and disable.fields() to enable and disable fields.


before.display:
The actions programmed in this subsection are executed each time that the specified field is displayed. You can use this subsection, for example, to set the value of a display field or to change the output format of currencies and dates (by using attr.oformat$). 


before.zoom:
When a zoom process is started on the specified field, the actions programmed in this subsection are executed immediately before the zoom process is executed. You can use this subsection to change the zoom attributes. For example, in the field definition in the form manager, a default zoom code can be specified. You can then use this subsection to change the zoom code (by setting the predefined variable attr.zoomcode). 


before.checks:
The actions programmed in this subsection are executed after input to the field has been completed and the TAB key has been pressed. The subsection is executed immediately before the domain and references are checked. You can use this section, for example, to change the value of the field before the domain and reference checks.


domain.error:
The actions programmed in this subsection are executed if the domain check causes an error after data has been entered in the field. You can use this section to provide your own error message instead of the standard message. 


ref.input:
The actions programmed in this subsection are executed if a reference error occurs. If you program this section, the standard program does not display a message. 


ref.display:
The actions programmed in this subsection are executed if there is an error in the reference display.


check.input:
The actions programmed in this subsection are executed immediately after the domain and reference checks. You can use this section to test for errors that are not detected automatically. If the standard program detects an error, input is automatically restarted. In a script, you can use set.input.error() to display an error message and start input again. 
This section is replaced by DAL functionality (if a DAL exists for the table).


on.input:
The actions programmed in this subsection are executed immediately after the check.input subsection. You can use this section, for example, to perform some appropriate action when the user enters a special character or to display a warning message in certain cases.


when.field.changes:
The actions programmed in this subsection are executed when the new value entered in the specified field differs from the old value.


after.zoom:
The actions programmed in this subsection are executed when the zoom process on a specified field ends. You can use this subsection, for example, to redisplay any field that has changed as a result of the zoom process.


after.input:
The actions programmed in this subsection are executed after all checks have been performed on input to the specified field and after the when.field.changes subsection has been executed. In this subsection, you can use the to.field() function if the sequence deviates from the default.


after.display:
The actions programmed in this subsection are executed just after display of the specified field. You can use this subsection, for example, to read reference tables.


after.field:
This is the last subsection for a field. The actions programmed in this subsection are executed after input to or display of the specified field. This section is always executed, even if the user left the field by pressing ESC, one of the arrow keys, or a mouse button. You can use this subsection to perform special actions before leaving the field.


Example
field.pctst099.item:
check.input:
select pctst001.*
from pctst001
where pctst001.item = :pctst099.item
as set with 1 rows
selectdo
....
selectempty
pctst001.dsca = "*****"
set.input.error(".....")
endselect
before.input:
if ..... then
attr.input = false
endif
after.display:
select pctst001.*
from pctst001
where pctst001.item = :pctst099.item
as set with 1 rows
selectempty


pctst001.dsca = "*****"
endselect


field.pctst099.date:
before.input:
attr.oformat$ = "%D002,2"

Related Post:

4GL Choice Section

You use choice sections to program actions that you want to be executed when standard commands are activated or ended. Choice sections consist of a main section and a subsection. The main section specifies the standard command for which the actions must be executed. The subsections specify when the actions must be executed.


Main section
choice.<standard command>:
The subsections associated with this main section are executed for the specified standard command. You use the Maintain Forms by Package VRC session to select the standard commands (ttadv3100m000) for each form. A list of standard commands appears at the end of this help topic.


Subsections
before.choice:
The actions programmed in this subsection are executed immediately before the specified command is executed. You can use this subsection, for example, to test data before the command process continues. You can use the choice.again() function to stop the command.


on.choice:
The actions programmed in this subsection are executed when the specified command is activated. These actions are executed instead of the standard action associated with the command. This subsection is available for the following commands only:

  • print.data
  • run.job
  • global.delete
  • global.copy
  • bms
  • all commands in type 4 programs (except modify.set, restart.input, end.program, abort.
  • program)

after.choice:
The actions programmed in this subsection are executed immediately after the specified command has been executed. This subsection is not available for the end.program and abort.program commands.


 Example
choice.first.view:
after.choice:
execute(first.set)


Related Post:

4GL Group Section

With dynamic forms, the mapping of groups to forms is not fixed. Consequently, the only form section that is relevant to dynamic forms is the form.all section. When dealing with dynamic forms, you use group sections instead of form sections


You use group sections to program actions that you want to be executed when particular groups are activated or ended. Group sections consist of a main section and a subsection. The main section specifies the particular group(s) for which the actions are to be executed. The subsections specify when the actions must be executed – for example, when the group is activated or when the group is ended.
Note: that a group becomes active when the form on which it occurs becomes current. 


Main section
group.<group number>:
This section defines the group for which the actions programmed in the group subsections are executed. The group number is automatically generated when the group is created. 


Subsections
init.group:
The actions programmed in this subsection are executed only the first time the group becomes active, immediately before the before.group subsection. You use this subsection to program the first action to be performed by the system when the group becomes active. When the group is split across two or more forms (because not all the group fits on one form or because it is a repeating group), this subsection is executed the first time that the first form on which the group occurs becomes current. 


Note: the init.group section for group.1 is the former init.form section for form.1. Group number 1 is not one of the groups in the form-definition.


before.group:
The actions programmed in this subsection are executed each time the specified group becomes active. When the group is split across more than one form, this subsection is executed whenever any form on which it occurs becomes current.


after.group:
The actions programmed in this subsection are executed each time the form on which the group occurs is ended. When the group is split across more than one form, this section is executed whenever any form on which the group occurs is ended.


Related Post:

Share

Twitter Delicious Facebook Digg Stumbleupon Favorites More