When is SELECT FOR UPDATE used

DB version:10gR2
Since another thread of mine on this subject didn't go well, i am starting another thread.
When exactly is SELECT..FOR UPDATE statement used? With the exception of using SELECT...FOR UPDATE in CURSOR declaration, I've rarely seen SELECT ...FOR UPDATE being used explicitlyby PL/SQL gurus in our firm. Why didn't they use SELECT..FOR UPDATE(i mean a stand alone SELECT FOR UPDATE, <em>not as a part of Cursor</em>) to lock rows before UPDATE/DELETE/INSERT in their codes?
Edited by: M.Everett on Oct 20, 2008 12:00 PM
edited the initial post to let the users know that I am refering to a stand alone SELECT FOR UPDATE statement, not the part of a cursor

M.Everett wrote:
What i gather from various sources in the Internet:
1. SELECT FOR UPDATE is used mainly on CURSORs and very rarely used as a stand alone statement (if this is not the case you would have seen SELECT FOR UPDATE statements before every UPDATEs and DELETEs in PL/SQL codes)
2. Stand alone SELECT FOR UPDATEs are used mainly when dealing with CLOB, BLOB
Am i right in making these conclusions?1. This is probably a fair assumption.
2. Not really. SELECT FOR UPDATE is not a requirement when dealign with (C|B)LOBs.
SELECT FOR UPDATE allows an easy form of reference when you come to update rows in a cursor loop (although cursor loops should be rarely used), because rather than having to include a where condition on key columns you can just refer to the CURRENT ROW. Obviously, the main reason for using SFUs is the locking and this can become a requirement in some business environments where a user "picks up" a record to deal with and other users will then not see that record in their list or be able to select it for themselves.
;)

Similar Messages

  • When does select for update release locks

    Hello all,
    Does anyone know when Oracle realeases the row locks when a
    select for update is issued?
    Does Oracle realase the row lock at the time when an actual update statement is
    issued for the locked row, or does it wait until a commit statment is executed?
    So for example, can I lock several rows with a select for update clause, and then
    issue update statements as many times as I want on each locked row without
    having to worry about the lock being released until I issue a commit statement.
    Thanks,
    David

    yes.
    The lock is released only when your transaction ends. A transaction can end because of:
    1). Commit.
    2). Rollback.
    3). client disconnects.
    etc. etc...

  • Clarification on SELECT for UPDATE

    HI All,
    I am doing a SELECT FOR UPDATE using NOWAIT as well as SKIPLOCKED option. I have question regarding the general behavior.
    Suppose let say , I have two tables (table1 and table 2 ).
    TABLE 1
    header_id NUMBER,
    service_id NUMBER
    TABLE 2
    header_id NUMBER,
    line_id NUMBER,
    status VARCHAR2
    And I run the following query
    SELECT t2.header_id, t2.line_id
    FROM table1 t1, table2 t2
    WHERE t1.header_id = t2.header_id
    AND t1.service_id = 1
    AND t2.status = 'SUCCESS'
    FOR UPDATE OF t2.status NOWAIT SKIP LOCKED;
    Questions
    1) Does adding both the NOWAIT and SKIP LOCKED in the sql help or just SKIP LOCKED would do fine.
    2) Lets say this SQL is executed when there are no rows with status as 'SUCCESS' in table2. Would this cause any performance impact. Like for example since its joining with table1 with table 2 based on the header id .Would it lock any rows on table1?
    ( My understanding was that it would not lock any row until it finds out any row with status as 'SUCCESS' but getting some conflicting answers)
    Thanks,
    Vj

    AKVK wrote:
    ( My understanding was that it would not lock any row until it finds out any row with status as 'SUCCESS' but getting some conflicting answers)THis would be my understanding too.
    To be sure make a test.
    Do the select for update so that it does not lock any rows.
    Then check the data dictionary select * from v$lock; to see for your session if there are any locks.

  • Should i use SELECT for update NOWAIT ?

    Hi:
    Do I need to use, in my pl/sql triggers and procedures, the SELECT FOR UPDATE NOWAIT sentence, to avoid locks before using update table sentences ? Is it common to use it on stored procedures and triggers?
    Thanks
    Joao Oliveira

    First, what, exactly do you mean by "avoid locks"? I was interpreting that to mean "I want to avoid creating locks in my session that might block someone else", not "I want to avoid having my SELECT wait for locks to be released-- I want it to fail immediately". If you meant the latter, then SELECT ... FOR UPDATE NOWAIT would be what you want. If you meant the former, then pessimistic locking is not what you want.
    Second, what sort of Oracle Forms architecture do you have? Are you still using old-school client-server applications? Or are you using a three-tiered approach? As Tom discusses in that thread, pessimistic locking is only an option when your client application is able to maintain database state across calls (i.e. client/server systems) not when you have stateless connections (which is the norm in the three-tier model). The old client-server versions of Forms would automatically and transparently do pessimistic locking. Since you didn't mention anything about your architecture, most of us probably assumed the more common stateless client architecture (note how Tom's answers progress over the 5 years in that thread as client/server architecture became less and less common).
    Third, while your question is appropriate for either the Database - General forum or the SQL and PL/SQL forum, that generally means that you are free to post it either forum, not that it should be posted in both. The vast majority of the folks that hang out in one forum hang out in the other. It's also rather frustrating to answer a post in one forum only to discover that there is another post in a different forum where someone else had already covered the same points half an hour earlier or to discover that there was additional information in another thread that might have changed your answer.
    Fourth, if you are going to do pessimistic locking, that requires that you are able to maintain state across various database calls, that you are locking on the lowest possible level of granularity, and that you are able to time out sessions relatively aggressively to ensure that someone doesn't open a record, thereby locking it, go to lunch (or have their system die) and then block everyone else from working. Assuming that is the case, and that you have some reasonable way to handle the error that gets generated other than simply retrying the operation, adding NOWAIT is certainly an option. Most applications, particularly those getting written today, cannot guarantee all these things, so pessimistic locking is generally not appropriate there.
    Looking at your other thread (where there is new information that would be useful in this discussion, one of the reasons that multiple threads are generally a bad idea), it seems that you have an ERP application and you are concerned about the performance of entering orders. Obviously, there shouldn't be any locking issues on the ORDER or ORDER_DETAILS tables, assuming that multiple users aren't going to be inserting the same order at the same time. The contention would almost certainly come when multiple orders are trying to update the STOCK and INVENTORY tables, since multiple orders presumably rely on the same rows in those tables. In that case, I'm not sure what adding a NOWAIT would buy you-- unless you were going to roll back the entire order because someone is updating the STOCK row for #2 pencils and your order has an item of #2 pencils, you'd have to keep retrying the operation until you were able to modify the STOCK row, which would be less efficient than just letting that update block until the row was free.
    Now, you could certainly redesign the application to minimize that contention by not trying to update what I assume are aggregate tables like STOCK and INVENTORY directly as part of your OLTP processing or, at least, by minimizing the time that you're locking a row. You could, for example, make STOCK and INVENTORY materialized views rather than tables that refresh ON COMMIT, which should decrease the time that your locks are held. You could also have those tables refreshed asynchronously, which would be even more efficient but may require that you reasses your holdback requirements.
    Justin

  • I am updating iphoto 9.1 to 9.3 and every time when I clicked for update aps store asked to open it in the account where you purchased. I am using the same account and its available in the purchased item of this account. Can someone resolve this problem.

    I am updating iphoto 9.1 to 9.3 and every time when I clicked for update aps store asked to open it in the account where you purchased. I am using the same account and its available in the purchased item of this account. But in my purchased item library it indicates that you update iPhoto. I am not sure which account the aps store asking. Can someone resolve this problem.

    Contact App Store support. They're the folks who can help with Account issues.
    Regards
    TD

  • HT4972 I'm trying to update my iphone 3G to ios5 - however in Itunes when I 'check for updates' it is advising me that I have the latest version (4.2.1). Hence I can't update and now I can't run a few of the apps I previously used. Help!

    Following a backup and restore of my iphone 3g I have lost the use of a number of apps - this seems to be as they need ios5 or later to support them and I only have 4.2.1
    When I check for updates via itunes I am advised that I have the latest version - but clearly I don't.
    Any help gratefully received on how I can upgrade to ios5
    Yally

    Sadly, the iPhone 3G can not be upgraded beyond iOS 4.2.1.

  • Performance of using a Select For Update vs a correlated subquery

    I was wondering wether or not it is more effecient to use the
    Select ... For Update (with a cursor etc.) versus a correlated
    subquery.
    I can accomplish the same thing with either however performance
    at our site is an issue.

    Use select for update cursor as that is faster as it updates
    based on the rowid. One thing to keep in mind is that rowid is
    session specific and the rows to be updated get locked so that
    nobody else can update them till the lock is released. I have
    had very good performance results with these cursors.
    Good luck !
    Sudha

  • OpenSQL DataSource not allowed if select-for-update is used Error?

    Hi,
    I have created an enterprise application, EJB (Session + entity) + WAR, and corresponding ear file deployes with the following warning message, I have done similar apps in the past without erros.
    Warning: DataSource TMP_EMPLOYEES_DATA is OpenSQL. It is used by an abstract schema that uses select-for-update locking. It is now allwed to use OpenSQL DataSource if select-for-updaet is used.
    Any idea?
    Thanks

    Hi Ezatullah, all,
    while I do not propose an alternative solution, I'd like to add some explanation to the error message itself: Open SQL for Java strives to provide portable semantics across the set of supported databases and does not offer features which can not be provided by all the databases.
    Now, a SELECT .. FOR UPDATE in the semantics as used here is not generally available, in particular not regarding the locking semantics.
    Thus, the feature is rejected in combination with a Open SQL/JDBC data source.
    Best Regards, Dietmar

  • Difference in select for update of - in Oracle Database 10g and 11g

    Hi, I found out that Oracle Database 10g and 11g treat the following PL/SQL block differently (I am using scott schema for convenience):
    DECLARE
      v_ename bonus.ename%TYPE;
    BEGIN
      SELECT b.ename
        INTO v_ename
        FROM bonus b
        JOIN emp e ON b.ename = e.ename
        JOIN dept d ON d.deptno = e.deptno
       WHERE b.ename = 'Scott'
         FOR UPDATE OF b.ename;
    END;
    /While in 10g (10.2) this code ends successfully (well NO_DATA_FOUND exception is raised but that is expected), in 11g (11.2) it raises exception "column ambiguously defined". And that is definitely not expected. It seems like it does not take into account table alias because I found out that when I change the column in FOR UPDATE OF e.empno (also does not work) to e.mgr (which is unique) it starts working. So is this some error in 11g? Any thoughts?
    Edited by: Libor Nenadál on 29.4.2010 21:46
    It seems that my question was answered here - http://stackoverflow.com/questions/2736426/difference-in-select-for-update-of-in-oracle-database-10g-and-11g

    The behaviour seems like it really is a bug and can be avoided using non-ANSI syntax. (It makes me wonder why Oracle maintains two query languages while dumb me thinks that this is just a preprocessor matter and query engine could be the same).

  • Deadlock detected during SELECT FOR UPDATE - an application error?

    I have a general question about how Oracle prevents deadlocks from affecting
    applications: do I need to build support into the application for handling
    deadlocks when they occur in this particular scenario, or should Oracle handle
    this for me? I'd like to know whether this is "normal" behavior for an Oracle
    application, or if there is an underlying problem. Consider the following situation:
    Two sessions issue individual SELECT FOR UPDATE queries. Each query locates
    records in the table using a different index. These indexes point to rows in a
    different order from each other, meaning that a deadlock will occur if the two
    statement execute simultaneously.
    For illustrative purposes, consider these rows in a hypothetical table.
    ALPHABET
    alpha
    bravo
    charlie
    delta
    echo
    foxtrot
    golf
    hotel
    Index A results in traversing the table in ascending alphabetical order; index
    B, descending. If two SELECT FOR UPDATE statements concurrently execute on this
    table--one with an ascending order execution path and one in descending order--
    the two processes will deadlock at the point where they meet. If Session A
    locks alpha, bravo, charlie, and delta, while Session B locks hotel, golf,
    foxtrot, and echo, then neither process can proceed. A needs to lock echo, and
    B needs to lock delta, but one cannot continue until the other releases its
    locks.
    This execution path can be encouraged using hints. Executing queries similar to these on larger tables will generate the "collision" as described above.
    -- Session A
    select /*+ index_asc (customer) */
    from customer
    where gender = 'M'
    for update;
    -- Session B
    select /*+ index_desc (customer) */
    from customer
    where gender = 'M'
    for update;
    Oracle will recognize that both sessions are in a stand-off, and it will roll
    back the work performed by one of the two sessions to break the deadlock.
    My question pivots on whether or not, in this situation, the deadlock gets
    reported back to the application executing the queries as an ORA-00060. If
    these are the ONLY queries executed during these sessions, I would think that
    Oracle would rollback the locking performed in one of the SELECT FOR UPDATE
    statements. If I understand correctly,
    (1) Oracle silently rolls back and replays work performed by UPDATE statements
    when a deadlock situation occurs within the scope of the update statement,
    and
    (2) A SELECT FOR UPDATE statement causes Oracle, at the point in time the cursor
    is opened, to lock all rows matching the WHERE clause.
    If this is the case, then should I expect Oracle to produce an ORA-00060
    deadlock detection error for two SELECT FOR UPDATE statements?
    I would think that, for deadlock situations completely within Oracle's control,
    this should be perceived to the application invoking the SELECT FOR UPDATE
    statements as regular blocking. Since the query execution plans are the sole
    reason for this deadlock situation, I think that Oracle would handle the
    situation gracefully (like it does for UPDATE, as referenced in (1)).
    Notice, from the trace file below, that the waits appear to be from row locking,
    and not from an artificial deadlock (e.g. ITL contention).
    Oracle8i Enterprise Edition Release 8.1.7.4.0 - 64bit Production
    With the Partitioning option
    DEADLOCK DETECTED
    Current SQL statement for this session:
    SELECT XXX FROM YYY WHERE ZZZ LIKE 'AAA%' FOR UPDATE
    ----- PL/SQL Call Stack -----
    object line object
    handle number name
    58a1f8f18 4 anonymous block
    58a1f8f18 11 anonymous block
    The following deadlock is not an ORACLE error. It is a
    deadlock due to user error in the design of an application
    or from issuing incorrect ad-hoc SQL. The following
    information may aid in determining the deadlock:
    Deadlock graph:
    ---------Blocker(s)-------- ---------Waiter(s)---------
    Resource Name process session holds waits process session holds waits
    TX-002f004b-000412cf 37 26 X 26 44 X
    TX-002e0044-000638b7 26 44 X 37 26 X
    session 26: DID 0001-0025-00000002     session 44: DID 0001-001A-00000002
    session 44: DID 0001-001A-00000002     session 26: DID 0001-0025-00000002
    Rows waited on:
    Session 44: obj - rowid = 0000CE31 - AAANCFAApAAAAGBAAX
    Session 26: obj - rowid = 0000CE33 - AAANCHAArAAAAOmAAM
    Thanks for your insight,
    - Curtis
    (1) "Oracle will silently roll back your update and restart it"
    http://tkyte.blogspot.com/2005/08/something-different-part-i-of-iii.html
    (2) "All rows are locked when you open the cursor, not as they are fetched."
    http://download-east.oracle.com/docs/cd/A87860_01/doc/appdev.817/a77069/05_ora.htm#2170
    Message was edited by:
    Curtis Light

    Thanks for your response. In my example, I used the indexes to force a pair of query execution plans to "collide" somewhere in the table in question by having one query traverse the table via index in an ascending order, and another in descending. This is an artificial scenario for reproducible illustrative purposes, but similar collisions could legitimately occur in real world scenarios (e.g. a full table scan and an index range scan with lookup by ROWID).
    So, with that said, I think it would be unreasonable for Oracle to report the collision as a ORA-00060 every time it occurs because:
    (1) The UPDATE statement handles this situation automatically, and
    (2) An ORA-00060 results in a 100+KB trace file being written out, only rational for truly erroneous situations.
    I agree that, when the application misbehaves and locks rows out of order in separate SQL statements, then Oracle should raise an ORA-00060, as the deadlock is outside of its control. But in this case, the problem occurs with just two individual SQL statements, each within its own transaction.

  • Pros and  cons  of  select  for  update  clause

    hi,
    Can anybody explain what are the
    pros and cons of select for update clause
    11.2.0.1

    As commented, there are no pros versus cons in this case.
    What is important is to understand conceptually what this do and why it would be use.
    Conceptually, a select for update reads and locks row(s). It is known as pessimistic locking.
    Why would you want to do that? Well, you have a fat client (Delphi for example) and multiple users. When userA updates an invoice, you want that invoice row(s) locked and prevent others from making updates at the same time. Without locking, multiple users updating the same invoice will result in existing updated data being overwritten by old data that also has been updated. A situation called lost updates.
    For web based clients that are stateless, pessimistic locking does not work - as the clients do not have state and pessimistic locking requires state. Which means an alternative method to select for update needs to be used to prevent lost updates. This method is called optimistic locking.
    So it is not about pros versus cons. It is about understanding how the feature/technique/approach works and when to use it.. and when it is not suited to use it. All problems are not nails. All solutions are not the large hammer for driving in nails.

  • Inconsistent Locking with Select for Update

    Hi,
    I seem to be having some issues in using SELECT FOR UPDATE and was hoping to get some insight from the Oralce Guru's out there.
    I have a J2EE application, running in WebLogic 8.1.4 using Oralce 9.2.0.1.0.
    The application contains code that requires locking to be done on a specific table with multiple transactions (tx) requesting the same lock. Eg:
    Tx 1: Select * from Zone where Zoneid = 'Zone1' for update (Obtains lock)
    Tx 2: Select * from Zone where Zoneid = 'Zone1' for update (waits)
    Tx 100: Select * from Zone where Zoneid = 'Zone1' for update
    Tx1 commits.
    It appears that the following transactions, i.e. Tx2 - Tx100 do not seem to execute in the order the lock was requested. That is Tx 100 always appears to be the second last transaction to execute, after which some arbitrary transaction between Tx2 - Tx99 will execute after Tx100 has committed.
    This seems to tell me that the lock is not being handed in a FIFO manner and is causing us great pain as our data is not longer consistent.
    Does anyone know how i might be able to trace which transaction is being awarded the lock? Also if anyone has any suggestion on how to troubleshoot/solve this issue, greatly appreciated.
    TIA
    Prem

    Oracle does not have a lock queue/manager at all. The locked status of a record is essentially an attribute of the record itself. It is stored on the datablock header. When a transaction requests a lock and can't get it, and is willing to wait (SELECT FOR UPDATE without NOWAIT), it first spins while waiting for the lock (four times as I recall), then sleeps waiting for the lock. The the more times it sleeps before getting the lock, the longer it will sleep before trying again.
    What is likely happening here is that transaction 100 is still spinning when transaction 1 commits, so checks back more frequently and gets the lock first. The rest get the lock whenever they wake up and noone else has taken the lock.
    If you need the transaction to occur in order, then I do not think you can use Oracle's native locking mechanism. Depending on what exactly you are trying to do, you may want to look at Advanced Queueing, or possibly the built-in package DBMS_LOCK.
    HTH
    John

  • Database select for update locks ADF

    Hi,
    When a user has initiated an update session in an adf application and locking is optimistic it will acquire a lock on table row using select for update no wait; . But when the user closes a tab the session would not be terminated. Now i know as HTTP is a stateless protocol, we can wait for the timeout and then the lock will be released using a session listener implementation. But if the user instead tries to log in again in a new tab and tries to edit the same record he will receive a message stating that another user already holds a lock on the record which is correct, but is misleading.
    So can we rely on javascript for these scenarios that as soon as the user closes the tab the session should be terminated.
    Here's a snippet
    <script type="text/javascript" src="http://ajax.googleapis.com/ajax/libs/dojo/1.4/dojo/dojo.xd.js" ></script>
    <script type="text/javascript">
    var unLoad = function() {
        dojo.io.script.get({
        url:'http://127.0.0.1:7101/myapp/adfAuthentication?logout=true',
        timeout:15000,
      dojo.addOnWindowUnload(unLoad);
    </script>I know this might not work always as it depends on the fact that request might / might not be processed by the server.
    Are there any alternate solutions and also reducing the session timeout is ruled out in my scenario.

    Ramandeep,
    So are there other alternatives or solutionsAlternatives or solutions to what, exactly? As Jobinesh has told you, as long as you use optimistic locking, ADF doesn't acquire database locks except in the context of a transaction that is going to be completed in the current HTTP request. You could obviously force ADF to deviate from this if you called "postChanges" during an HTTP request and leave the transaction hanging, but that would just be wrong in an optimistic locking scenario - the solution would be "don't do that."
    John

  • Updatable View issues:  cannot select FOR UPDATE from view with DI

    Hi All,
    I have a simple view XY and an instead of trigger on that to insert data into one table which is used in the my view. When I do insert statement on view XY it is working fine from sql but when i used same thing with page process of " Process Row of XY Automatic Row Processing (DML) " i am getting following error. I am using APEX 3.0 . Please help me.
    ORA-20001: Error in DML: p_rowid=xxxx, p_alt_rowid=abc, p_rowid2=, p_alt_rowid2=. ORA-02014: cannot select FOR UPDATE from view with DISTINCT, GROUP BY, etc.
    Thanks

    James,
    are you already on 3.0.1.00.07 or 3.0.1.00.08? Have a look at the release notes, it says something about a bug fix for some occurrences of ORA-02014.
    Also have a look at the new substitution value/item FSP_DML_LOCK_ROW which turns locking off if you set it to FALSE. See http://www.oracle.com/technology/products/database/application_express/html/3.0.1_readme.html#CHDIDIAF and also http://download-west.oracle.com/docs/cd/B32472_01/doc/appdev.300/b32471/advnc.htm#BCGFDAIJ
    Patrick
    My APEX Blog: http://inside-apex.blogspot.com
    The ApexLib Framework: http://apexlib.sourceforge.net
    The APEX Builder Plugin: http://apexplugin.sourceforge.net/ New!

  • Select for update on stateless connections

    i have read that using select for update for a web application will not work specially if the stateless connection are used , and the best way to make sure that the column you are reading was not changed is to use the time stamp approach and not select for update?? i am right

    Not entirely correct.
    A connection/session to Oracle has state. There is no such thing as a stateless Oracle connection.
    The stateless connection is from the web browser to the web server. It makes a connection. Asks for a page (GET, PUT or POST typically). It gets a response from the web server. It closes that connection.
    When the web server response, it opens a (stateful) connection to Oracle. Or it re-uses an existing (stateful) Oracle connection (now idle after having serviced another web browser/web server request).
    The problem with pessimistic locking (e.g. SELECT FOR UPDATE) is that the very same (stateful) Oracle session will either
    a) be closed when a response is send to the web browser
    b) be used for another totally different web browser
    Thus any locks made will either be lost (option a) or will get used by the wrong web browser (option b).
    A method is therefore needed to make the lock spans different Oracle (stateful) sessions. Web browser selects rows to update using Oracle session 101 at Time 1. Web browser submits updated rows and a commit using Oracle session 142 at Time 2.
    The "best way" to handle optimistic locking is likely using the Oracle System Change Number (SCN). This represents the "current version" of the rows.
    So at Time 1, via Session 101, you give the web browser a 100 rows to update - together with the SCN that says the current version of the rows are v1.2.0.1.
    At Time 2, using Session 142, the web browser submits its changes for those 100 rows. Together with the SCN v1.2.0.1.
    The SQL UPDATE issues the update statement - but adds the SCN version criteria. If the UPDATE fails to update all 100 rows, it means that some of the rows no longer exist, or that some rows have a new version number (was changed in the meantime).
    In this case, the UPDATE is rolled back and an exception raised to tell the web browser that some (or all) of those 100 rows have been changed in the meantime.
    Refer to the [url http://download.oracle.com/docs/cd/B19306_01/server.102/b14200/pseudocolumns007.htm#BABFAFIC]Oracle® Database SQL Reference for details.

Maybe you are looking for

  • F.01 - extract to consolidation on company code level

    Hi everyone We're trying to do an extract to consolidation on company code level (1). When popup dialog "Filename for extraction file" appears we can choose between presentation server or application server. When choosing presentation server and logi

  • Connecting to an sql server db

    I have a need of connecting to a MS Sql Server from and Oracle Db to transfer data upon request from the MS Sql Server to the Oracle Db. For various reasons the user wants to avoid many of the various middleware solutions that otherwise might be appl

  • Collection Errors in Grid Control Sybase Plugin

    Hi. I have some collection failures in a Sybase 15 Database i registered to Grid Control using the Sybase ASE Plugin. These are the 3 of them: Result has repeating key value : 0,5,0,, Result has repeating key value : 0000000000000000000000000000,2008

  • Project Variables Labels Not Updated After Change in OBPM 10GR3

    Hi all, I had previously deployed a project to the Weblogic Enterprise Server with a set of project variables , layouts, presentations and views. Now, I changed the labels to the Project Variables using Studio. Made them all Upper Case and re-deploye

  • Noob question. SWF file runs as slideshow, does not allow navigation.

    Hi. I run my own company, and hired a professional to design my website in Flash. I have the editable .fla file in my possession and given that what I need is really simple, I´d like to do it myself and start knowing the tool by reverse engineering a