User Controls - Uploadify

Uploadify allows an easy upload of files from GeneXus web applications. We can define the extensions of the files that need to be uploaded, set the maximum size of files to upload and simultaneously upload multiple files. The files we select can be stored in the database in Blob type field. Following are the simple steps to use this control.
 

1.    Install the User Control from GeneXus Marketplace and restart GeneXus. http://marketplace.genexus.com/product.aspx?uploadify,en

2.    Drag and drop the Uploadify control from Toolbox under Misc. List on the Web Panel. With this, it provides an example in events section.

Event Uploadify1.OnAllComplete

  for &File in &UploadedFiles

    msg(&File.OriginalFileName)

  endfor

EndEvent    

Event Uploadify1.OnCancel

  &File = Uploadify1.File

  msg("Cancel:" + &File.OriginalFileName)

EndEvent

Event Uploadify1.OnError

  &File = Uploadify1.File

  msg("Error uploading file:" + &File.OriginalFileName)

  msg(Uploadify1.Error)

EndEvent

3.    After a successful upload, OnAllComplete event would be triggered. The events such as OnCancel, OnError, OnComplete, OnSelect and OnSelectOnce are available with the control.

4.    The Size upload limit and simultaneous upload limit can be set through properties. These properties can be changed and validated during runtime too.

5.    During the file upload and it’s insertion in the database (as blob entry), the uploaded file gets stored at the PublicTempStorage directory at KB installation location. For a java web application, it gets created at - C:\Program Files (x86)\Apache Software Foundation\Tomcat 7.0\webapps \<KBName>KBJavaEnvironment

6.    To save the uploaded file in the database, we need to use the temporal full path to a blob variable.

&blob = &UploadedFile.TemporalFileName

If we are using this user control in a java web application, we must include the following files in war for WebSphere deployment.

1. upload.jar file in WEB-INF\lib\ location
2. drivers folder structure at WEB-INF\lib\

Working with KB properties – Isolation Level

We faced a record lock issue some time back where our program was fetching values for a particular record from a transaction. If the record we were trying to read from, was open in Edit mode at the backend (AS/400), the procedure trying to read the data was getting aborted saying the Record has been locked (Java Front End). The easiest way to solve this issue was to change the Isolation Level property from Read Committed to Read Uncommitted.

Isolation Level Property in Java Web generator can be very useful for minimizing the Record Locks. GeneXus EV2 provides two types of Isolation Levels. 

1. Read Committed – The changes from one user are not available for the other users unless the changes are committed. So a transaction executing under this isolation level can only access the committed data. This is a default setting.

Pros: Data retrieved is consistent.

Cons: Can throw Record Locks and abort the process.

  

2. Read Uncommitted – The changes from one user are available for all users even if not committed. (This usually is a dirty read). So, if the first user updates some data, it can be read by other users even though first user can do the rollback of the read updates.

Pros: Quick performance, No record locks.

Cons: Data received may be inconsistent.