Iron Speed Designer>Working with Microsoft Visual Studio .NET

Opening a Generated Application in Visual Studio .NET

Microsoft Visual Studio 2003

Follow these steps to open an Iron Speed Designer-generated application in Microsoft Visual Studio .NET 2003:

• Step 1: In Visual Studio .NET 2003, select File, Open, Project to display the Open Project dialog.
  
• Step 2: Select an application folder from the Open Project dialog, and click the Open button.
  
• Step 3: Select the *.CSPROJ or *.VBPROJ file, and click the Open button.
  

Microsoft Visual Studio 2005

Follow these steps to open an Iron Speed Designer-generated application in Microsoft Visual Studio .NET 2005:

• Step 1: In Microsoft Visual Studio .NET, select File, Open, Web Site...
  
• Step 2: Select an application folder, and click the Open button.
  

Visual Studio Project Files

Iron Speed Designer automatically generates Visual Studio project files for Visual Studio 2003 applications (.NET Framework 1.1). These CSPROJ and VBPROJ files are created when Iron Speed Designer initializes your application, and they can be opened in Visual Studio 2003. Iron Speed Designer automatically updates your application’s project file every time the application is built in Iron Speed Designer.
Iron Speed Designer does not create a SLN file (“solution” file), because Visual Studio .NET automatically creates one if you open any Visual Studio project file.
Note: Visual Studio 2005 does not use project files, so Iron Speed Designer does not generate them for Visual Studio 2005 (.NET Framework 2.0) applications. To open a generated application in Visual Studio 2005, open it as a "web project."

Custom Controls Generated by Iron Speed Designer

The custom controls in the application classes are designed to integrate with Visual Studio .NET's Visual Designer, and are used in the user controls (the ASCX files) generated by Iron Speed Designer. This means that if you open one of the generated ASCX files using the Visual Studio .NET Visual Designer, you will be able to see the Iron Speed Designer custom controls, edit their custom properties using their property sheets, add them to your Visual Studio .NET Toolbox, etc.
The web controls in the application classes contain special .NET meta-tags in their code to enable this integration with Visual Studio .NET. You need take no special action to use these controls. These controls are already used in the web pages generated by Iron Speed Designer, so the web pages may be opened directly in Visual Studio .NET.

Enabling and Disabling Strict Compilation Mode

You can enable or disable "strict mode" compilation in Visual Studio .NET. Locate the CompileApplication.rsp file in your application folder:

...\\CompileApplication.rsp

CompileApplication.rsp may contain the optionstrict tag. To enable strict mode, change this setting to:

/optionstrict+

To disable strict mode, change the setting to:

/optionstrict-

Compiling Applications in Debug Mode

Iron Speed Designer creates a standard .NET application so you can use the debugging features of Microsoft Visual Studio .NET to debug your applications. When an application is created, a VBPROJ or a CSPROJ file is created along with the source files. You can open this project file in Visual Studio .NET, compile your application with debugging information, and set breakpoints to stop at any point in your application.
Note: Visual Studio .NET requires an application resident on the local machine for debugging purposes.

• Step 1: Open your application in Visual Studio .NET.
• Step 2: In Microsoft Visual Studio, select Build, Configuration Manager. This displays the Configuration Manager dialog.
• Step 3: Select a Active Solution configuration.
  
• Step 4: Give it a name such as "Debug", and click "OK".
  Visual Basic .NET applications:
  In the Solution Explorer, right-click the solution’s name and select Properties. Then, select the Configuration Properties and the Build option in this group. You will notice a check box titled "Generate Debugging Information" in the panel to the right. Make sure you check this control.
  
  C# applications:
  In the Solution Explorer, right-click the solution’s name and select Properties. Select the Configuration Properties and the Build option in this group. You will notice a property titled "Generate Debugging Information" in the panel to the right. Make sure the value for this property is set to True.
  
  
• Step 5: Click the "Close" button in the Configuration Manager. Notice that the project can now be compiled in "Debug" mode via Visual Studio .NET.
  
• Step 6: Change your application’s Web.config file for debugging mode:

  <compilation defaultLanguage="c#" debug="true" />

  or
  

  <compilation defaultLanguage="vb" debug="true" />

  Set compilation debug="true" to insert debugging symbols (*.pdb information) into the compiled page. Because this creates a larger file that executes more slowly, you should set this value to true only when debugging, and to false at all other times. For more information, refer to the documentation about debugging ASP.NET files.
  Note: For faster performance, we recommend your application be compiled in Release mode.
  

way to get connection for oracle developer 6i with oracle 10g +

way to get connection for oracle developer 6i with oracle 10g +

>sys as sysdba
SQL> startup restrict
>alter database character set internal_use UTF8;
SQL> shutdown immediate
SQL> startup

C:\Documents and Settings\admin>sqlplus "/ as sysdba"
C:\Documents and Settings\admin>lsnrctl

What's blocking my lock?

What's blocking my lock?

If you've ever gotten a phone call from an annoyed user whose transaction just won't go through, or from a developer who can't understand why her application sessions are blocking each other, you know how useful it can be to identify not just whose lock is doing the blocking, but what object is locked. Even better, you can identify the exact row that a session is waiting to lock.

Create a blocking lock

To begin, create a situation where one user is actively blocking another. Open two sessions. Issue the following commands in Session 1 to build the test table:

SQL> create table tstlock (foo varchar2(1), bar varchar2(1));

Table created.

SQL> insert into tstlock values (1,'a'); 

1 row created.

SQL> insert into tstlock values (2, 'b');

1 row created.

SQL> select * from tstlock ;

FOO BAR
--- ---
1   a
2   b

2 rows selected.

SQL> commit ;

Commit complete.

Now grab a lock on the whole table, still in Session 1:
SQL> select * from tstlock for update ;
And in Session 2, try to update a row:

SQL> update tstlock set bar=
  2  'a' where bar='a' ;

This statement will hang, blocked by the lock that Session 1 is holding on the entire table.

Identify the blocking session

Oracle provides a view, DBA_BLOCKERS, which lists the SIDs of all blocking sessions. But this view is often, in my experience, a good bit slower than simply querying V$LOCK, and it doesn't offer any information beyond the SIDs of any sessions that are blocking other sessions. The V$LOCK view is faster to query, makes it easy to identify the blocking session, and has a lot more information.

SQL> select * from v$lock ;

ADDR     KADDR           SID TY        ID1        ID2      LMODE    REQUEST      CTIME      BLOCK
-------- -------- ---------- -- ---------- ---------- ---------- ---------- ---------- ----------
AF9E2C4C AF9E2C60        479 TX     131078      16739          0          6        685          0
ADDF7EC8 ADDF7EE0        422 TM      88519          0          3          0        697          0
ADDF7F74 ADDF7F8C        479 TM      88519          0          3          0        685          0
ADEBEA20 ADEBEB3C        422 TX     131078      16739          6          0        697          1
....     ....            ... ...      ....       ....       ....       ....        ....      ....

Note the BLOCK column. If a session holds a lock that's blocking another session, BLOCK=1. Further, you can tell which session is being blocked by comparing the values in ID1 and ID2. The blocked session will have the same values in ID1 and ID2 as the blocking session, and, since it is requesting a lock it's unable to get, it will have REQUEST > 0.
In the query above, we can see that SID 422 is blocking SID 479. SID 422 corresponds to Session 1 in our example, and SID 479 is our blocked Session 2.
To avoid having to stare at the table and cross-compare ID1's and ID2's, put this in a query:

SQL> select l1.sid, ' IS BLOCKING ', l2.sid
  2  from v$lock l1, v$lock l2
  3  where l1.block =1 and l2.request > 0
  4  and l1.id1=l2.id1
  5  and l1.id2=l2.id2
SQL> /

       SID 'ISBLOCKING'         SID
---------- ------------- ----------
       422  IS BLOCKING         479

1 row selected.

Even better, if we throw a little v$session into the mix, the results are highly readable:

SQL> select s1.username || '@' || s1.machine
  2  || ' ( SID=' || s1.sid || ' )  is blocking '
  3  || s2.username || '@' || s2.machine || ' ( SID=' || s2.sid || ' ) ' AS blocking_status
  4  from v$lock l1, v$session s1, v$lock l2, v$session s2
  5  where s1.sid=l1.sid and s2.sid=l2.sid
  6  and l1.BLOCK=1 and l2.request > 0
  7  and l1.id1 = l2.id1
  8  and l2.id2 = l2.id2 ;


BLOCKING_STATUS
----------------------------------------------------------------------------------------------------
BULKLOAD@yttrium ( SID=422 )  is blocking BULKLOAD@yttrium ( SID=479 )

1 row selected.

There's still more information in the v$lock table, but in order to read that information, we need to understand a bit more about lock types and the cryptically-named ID1 and ID2 columns.

Lock type and the ID1 / ID2 columns

In this case, we already know that the blocking lock is an exclusive DML lock, since we're the ones who issued the locking statement. But most of the time, you won't be so lucky. Fortunately, you can read this information from the v$lock table with little effort.
The first place to look is the TYPE column. There are dozens of lock types, but the vast majority are system types. System locks are normally only held for a very brief amount of time, and it's not generally helpful to try to tune your library cache, undo logs, etc. by looking in v$lock! (See the V$LOCK chapter in the Oracle Database Reference for a list of system lock types.)
There are only three types of user locks, TX, TM and UL. UL is a user-defined lock -- a lock defined with the DBMS_LOCK package. The TX lock is a row transaction lock; it's acquired once for every transaction that changes data, no matter how many objects you change in that transaction. The ID1 and ID2 columns point to the rollback segment and transaction table entries for that transaction.
The TM lock is a DML lock. It's acquired once for each object that's being changed. The ID1 column identifies the object being modified.

Lock Modes

You can see more information on TM and TX locks just by looking at the lock modes. The LMODE and REQUEST columns both use the same numbering for lock modes, in order of increasing exclusivity: from 0 for no lock, to 6 for exclusive lock. A session must obtain an exclusive TX lock in order to change data; LMODE will be 6. If it can't obtain an exclusive lock because some of the rows it wants to change are locked by another session, then it will request a TX in exclusive mode; LMODE will be 0 since it does not have the lock, and REQUEST will be 6. You can see this interaction in the rows we selected earlier from v$lock:

ADDR     KADDR           SID TY        ID1        ID2      LMODE    REQUEST      CTIME      BLOCK
-------- -------- ---------- -- ---------- ---------- ---------- ---------- ---------- ----------
AF9E2C4C AF9E2C60        479 TX     131078      16739          0          6        685          0
ADEBEA20 ADEBEB3C        422 TX     131078      16739          6          0        697          1

Note that ID1 and ID2 in Session 2, which is requesting the TX lock (LMODE=0, REQUEST=6), point back to the rollback and transaction entries for Session 1. That's what lets us determine the blocking session for Session 2.
You may also see TX locks in mode 4, Shared mode. If a block containing rows to be changed doesn't have any interested transaction list (ITL) entries left, then the session acquires a TX lock in mode 4 while waiting for an ITL entry. If you see contention for TX-4 locks on an object, you probably need to increase INITRANS for the object.
TM locks are generally requested and acquired in modes 3, aka Shared-Row Exclusive, and 6. DDL requires a TM Exclusive lock. (Note that CREATE TABLE doesn't require a TM lock -- it doesn't need to lock any objects, because the object in question doesn't exist yet!) DML requires a Shared-Row Exclusive lock. So, in the rows we selected earlier from v$lock, you can see from the TM locking levels that these are DML locks:

ADDR     KADDR           SID TY        ID1        ID2      LMODE    REQUEST      CTIME      BLOCK
-------- -------- ---------- -- ---------- ---------- ---------- ---------- ---------- ----------
ADDF7EC8 ADDF7EE0        422 TM      88519          0          3          0        697          0
ADDF7F74 ADDF7F8C        479 TM      88519          0          3          0        685          0

Identifying the locked object

Now that we know that each TM row points to a locked object, we can use ID1 to identify the object.

SQL> select object_name from dba_objects where object_id=88519 ;

OBJECT_NAME
--------------
TSTLOCK

Sometimes just knowing the object is enough information; but we can dig even deeper. We can identify not just the object, but the block and even the row in the block that Session 2 is waiting on.

Identifying the locked row

We can get this information from v$session by looking at the v$session entry for the blocked session:

SQL> select row_wait_obj#, row_wait_file#, row_wait_block#, row_wait_row#
  2* from v$session where sid=479 ;

ROW_WAIT_OBJ# ROW_WAIT_FILE# ROW_WAIT_BLOCK# ROW_WAIT_ROW#
------------- -------------- --------------- -------------
        88519             16          171309             0

This gives us the object ID, the relative file number, the block in the datafile, and the row in the block that the session is waiting on. If that list of data sounds familiar, it's because those are the four components of an extended ROWID. We can build the row's actual extended ROWID from these components using the DBMS_ROWID package. The ROWID_CREATE function takes these arguments and returns the ROWID:

SQL> select do.object_name,
  2  row_wait_obj#, row_wait_file#, row_wait_block#, row_wait_row#,
  3  dbms_rowid.rowid_create ( 1, ROW_WAIT_OBJ#, ROW_WAIT_FILE#, ROW_WAIT_BLOCK#, ROW_WAIT_ROW# )
  4  from v$session s, dba_objects do
  5  where sid=543
  6  and s.ROW_WAIT_OBJ# = do.OBJECT_ID ;

OBJECT_NAME     ROW_WAIT_OBJ# ROW_WAIT_FILE# ROW_WAIT_BLOCK# ROW_WAIT_ROW# DBMS_ROWID.ROWID_C
--------------- ------------- -------------- --------------- ------------- ------------------
TSTLOCK                 88519             16          171309             0 AAAVnHAAQAAAp0tAAA

And, of course, this lets us inspect the row directly.

SQL> select * from tstlock where rowid='AAAVnHAAQAAAp0tAAA' ;

FOO BAR
--- ---
1   a

Conclusion

We've seen how to identify a blocking session, and how to inspect the very row that the waiting session is waiting for. And, I hope, learned a bit about v$lock in the process.

Oracle DBMS_LOCK Locks Locking

General Information
Source	{ORACLE_HOME}/rdbms/admin/dbmslock.sql
First Available	7.3.4
Constants	Name Description Data Type Value nl_mode NuLl INTEGER 1 ss_mode Sub Shared: used on an aggregate object to indicate that share locks are being acquired on subparts of the object INTEGER 2 sx_mode Sub eXclusive: used on an aggregate object to indicate that exclusive locks are being acquired on sub-parts of the object INTEGER 3 s_mode Shared: indicates that the entire aggregate object has a share lock, but some of the sub-parts may additionally have exclusive locks INTEGER 4 ssx_mod Shared SubeXclusive INTEGER 5 x_mode eXclusive INTEGER 6
Dependencies	SELECT referenced_name FROM dba_dependencies WHERE name = 'DBMS_LOCK' UNION SELECT name FROM dba_dependencies WHERE referenced_name = 'DBMS_LOCK';
Exceptions	Error Number Description ORA-20000 Unable to find or insert lock into catalog dbms_lock_allocated. ORU-10003 Unable to find or insert lock into catalog dbms_lock_allocated.
Object Privileges	GRANT execute ON dbms_lock TO
	GRANT execute ON dbms_lock TO uwclass;
ALLOCATE_UNIQUE
Allocates a unique lock identifier (in the range of 1073741824 to 1999999999) given a lock name. Lock identifiers are used to enable applications to coordinate their use of locks	dbms_lock.allocate_unique( lockname IN VARCHAR2, lockhandle OUT VARCHAR2, expiration_secs IN INTEGER DEFAULT 864000);
	See dbms_lock demo
CONVERT
Converts a lock from one mode to another Overload 1	dbms_lock.convert( id IN INTEGER, lockmode IN INTEGER, timeout IN NUMBER DEFAULT maxwait) RETURN INTEGER; Return Values 0 Success 1 Timeout 2 Deadlock 3 Parameter error 4 Don't own lock specified by id or lockhandle 5 Illegal lock handle
	See dbms_lock demo
Overload 2	dbms_lock.convert( lockhandle IN VARCHAR2, lockmode IN INTEGER, timeout IN NUMBER DEFAULT maxwait) RETURN INTEGER;
	See dbms_lock demo
RELEASE
Explicitly releases a lock previously acquired using the REQUEST function Overload 1	dbms_lock.release(id IN INTEGER) RETURN INTEGER; Return Values 0 Success 3 Parameter error 4 Don't own lock specified by id or lockhandle 5 Illegal lock handle
	See dbms_lock demo
Overload 2	dbms_lock.release(lockhandle IN VARCHAR2) RETURN INTEGER;
	See dbms_lock demo
REQUEST
Requests a lock with a given mode Overload 1	dbms_lock.request( id IN INTEGER, lockmode IN INTEGER DEFAULT x_mode, timeout IN INTEGER DEFAULT maxwait, release_on_commit IN BOOLEAN DEFAULT FALSE) RETURN INTEGER; Return Values 0 Success 1 Timeout 2 Deadlock 3 Parameter error 4 Don't own lock specified by id or lockhandle 5 Illegal lock handle
	See dbms_lock demo
Overload 2	dbms_lock.request( lockhandle IN VARCHAR2, lockmode IN INTEGER DEFAULT x_mode, timeout IN INTEGER DEFAULT maxwait, release_on_commit IN BOOLEAN DEFAULT FALSE) RETURN INTEGER;
	See dbms_lock demo
SLEEP
Suspends the session for a given period of time	dbms_lock.sleep(seconds IN NUMBER);
	exec dbms_lock.sleep(1.00);
Demo
-- create demo table CREATE TABLE lock_test ( action VARCHAR2(10), when TIMESTAMP(9)); GRANT insert ON lock_test TO public; CREATE OR REPLACE PACKAGE lock_demo IS v_lockname VARCHAR2(12) := 'control_lock'; v_lockhandle VARCHAR2(200); v_result PLS_INTEGER; -- obtain a lock PROCEDURE request_lock(p_ltype INTEGER, p_retval OUT INTEGER); -- release an existing lock PROCEDURE release_lock(p_retval OUT INTEGER); -- view the stored handle FUNCTION see_handle RETURN VARCHAR2; -- decode lock request FUNCTION decode_req(p_result PLS_INTEGER) RETURN VARCHAR2; -- decode lock release FUNCTION decode_rel(p_result PLS_INTEGER) RETURN VARCHAR2; END lock_demo; / CREATE OR REPLACE PACKAGE BODY lock_demo IS PROCEDURE request_lock(p_ltype IN INTEGER, p_retval OUT INTEGER) IS BEGIN IF v_lockhandle IS NULL THEN dbms_lock.allocate_unique(v_lockname, v_lockhandle); p_retval := dbms_lock.request(v_lockhandle, p_ltype); END IF; END request_lock; ------------------------------------------------------------ PROCEDURE release_lock(p_retval OUT INTEGER) IS BEGIN IF v_lockhandle IS NOT NULL THEN p_retval := dbms_lock.release(v_lockhandle); END IF; END release_lock; ------------------------------------------------------------ FUNCTION see_handle RETURN VARCHAR2 IS BEGIN IF v_lockhandle IS NOT NULL THEN RETURN v_lockhandle; ELSE RETURN 'Not Allocated'; END IF; END see_handle; ------------------------------------------------------------ FUNCTION decode_req(p_result PLS_INTEGER) RETURN VARCHAR2 IS retval VARCHAR2(20); BEGIN SELECT DECODE(p_result,0,'Success',1,'Timeout',2,'Deadlock', 3,'Parameter Error',4,'Already owned',5,'Illegal Lock Handle') INTO retval FROM dual; RETURN retval; END decode_req; ------------------------------------------------------------ FUNCTION decode_rel(p_result PLS_INTEGER) RETURN VARCHAR2 IS retval VARCHAR2(20); BEGIN SELECT DECODE(p_result,0,3, 'Parameter Error',4, 'Already owned', 5, 'Illegal Lock Handle') INTO retval FROM dual; RETURN retval; END decode_rel; ------------------------------------------------------------ END lock_demo; / GRANT execute ON lock_demo TO public; set serveroutput on -- get an exclusive lock in the current session (Session 1) DECLARE s VARCHAR2(200); BEGIN lock_demo.request_lock(6, s); dbms_output.put_line(s); END; / /* Two session request a shared lock (ss_mode). The shared lock cannot be acquired because session 1 holds an exclusive lock. Execution will stop on the request until the the exclusive lock is released. */ Session 2 Session 3 set serveroutput on DECLARE s VARCHAR2(200); BEGIN uwclass.lock_demo.request_lock( dbms_lock.ss_mode, s); dbms_output.put_line(s); INSERT INTO uwclass.lock_test (action, when) VALUES ('started', SYSTIMESTAMP); dbms_lock.sleep(5); INSERT INTO uwclass.lock_test (action, when) VALUES ('ended', SYSTIMESTAMP); COMMIT; END; / set serveroutput on DECLARE s VARCHAR2(200); BEGIN uwclass.lock_demo.request_lock( dbms_lock.ss_mode, s); dbms_output.put_line(s); INSERT INTO uwclass.lock_test (action, when) VALUES ('started', SYSTIMESTAMP); dbms_lock.sleep(5); INSERT INTO uwclass.lock_test (action, when) VALUES ('ended' , SYSTIMESTAMP); COMMIT; END; / -- Session 1 releases its lock DECLARE s VARCHAR2(200); BEGIN lock_demo.release_lock(s); dbms_output.put_line(s); END; / -- Execution resumes when the exclusive lock is released SELECT TO_CHAR(when,'dd.mm.yyyy hh24:mi:ss'), action FROM lock_test ORDER BY when;