SELECT FOR UPDATE via KODO queries

I want to do the following in a transaction:
1) SELECT * from Foo where type='x' FOR UPDATE
2) UPDATE Foo set sequence='22' where type='x'
3) commit
The issue: is there any way to force KODO to add the 'for update' in a find query.
Thanks

Please try kodo.LockManager configuration property.
-pessimistic: This is an alias for the kodo.jdbc.kernel.PessimisticLockManager , which uses SELECT FOR UPDATE statements (or the database's equivalent) to lock the database rows corresponding to locked objects. This lock manager does not distinguish between read locks and write locks; all locks are write locks.
Also please make sure you have following setting
kodo.jdbc.DBDictionary: SupportsSelectForUpdate=true
Please check kodo doc section 9.4.4.
JPA looks like
<property name="kodo.LockManager" value="pessimistic(VersionCheckOnReadLock=true,VersionUpdateOnWriteLock=true)"/>
JDO looks like
kodo.LockManager: pessimistic(VersionCheckOnReadLock=true,VersionUpdateOnWriteLock=true)
Thanks,
Yun

Similar Messages

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.

Rogue implicit SELECT FOR UPDATE statement in forms 9i 9.0.4.0.19

all,
out of 200 production forms, one form occasionally and incorrectly "selects for update" an entire 3 million row table, during an update transaction. this creates 100+ archive logs.
we cannot repeat the event via testing. but the rogue select statement has been captured from SGA and is listed below. its plain to see that somehow the where clause is truncated to a W, and is then used as a table alias, resulting in the entire table being locked.
has anyone seen anything like this?
SELECT ROWID,DISTRIBUTION_PARTY,DISTRIBUTION_PARTY_NAME,CORRESPOND_SEQ_NUM,DISTRIBUTION_SEQ_NUM,VENDOR_NUM,DEPENDENT_SEQ_NUM,INTERNAL_ATTORNEY_USER_NAME,MAIL_LOC,ORIGINAL_FLAG
FROM CLAIM_DISTRIBUTION_DATA W
FOR UPDATE OF DISTRIBUTION_PARTY NOWAIT

Find out where this select statement is issued from first of all. Is it in your code or is it issued implicitely by Forms? Since it has rowid I assume it is an implicit Forms call.
Do you use on-update triggers any where in this form? on-lock?

Lock Cascade With Select for UPDATE

If I had a employee table and a phone table with a parent/child relationship and a primary key constraint on the employee table-will issuing a select for update on the employee also lock the corresponding child rows on the phone table ?
If not how can I bring this about ?

You only need two sessions:
First session: Issue the 'select for update'
statements for the row(s) in both tables, don't
rollback or commit
Second session: try to update a row that you tried to
lock in the first session (with NOWAIT).
Thanks. I can try this definitely. A basic question.
You are asking me to do a join on both the tables right ?
Not two individual SQL statements ?
Updating the primary key is known as a Bad Idea (tm).
The key should never be touched because it should be
meaningless. When you have a column that holds 'real'
information it is no candidate for a primary key.
Rgds,
GuidoYes I am aware of that. I was just wondering what is the meaning behind this statement from this link ?
http://www.akadia.com/services/ora_locks_survival_guide.html
And the exact phrase from that link under the section Referential Integrity Locks (RI Locks)
"RI constraints are validated by the database via a simple SELECT from the dependent (parent) table in question-very simple, very straightforward. If a row is deleted or a primary key is modified within the parent table, all associated child tables need to be scanned to make sure no orphaned records will result. "
Thanks again.

JDBC SELECT FOR UPDATE

I'm trying to issue a SELECT ... FROM ... FOR UPDATE, and under specific verified conditions runs an UPDATE (where the current is positioned!).
The error code I get is:
ORA-01002: Fetch out of sequence.
Here you are my code:
/////////////////////START
import java.sql.*;
import oracle.jdbc.*;
import oracle.sql.*;
public class SelForUpdDin{
static{
     try{
          Class.forName("oracle.jdbc.driver.OracleDriver");
     catch(Exception e){e.printStackTrace();}
// Queries and cursor name
public static void main (java.lang.String[] args){
String cursorName = null;
int codice = 0;
String cognome = null;
String job = null;
int manager = 0;
java.sql.Date dataAss = null;
int salario = 0;
int commissioni = 0;
int reparto = 0;
String rowid = null;
String sqlSelect = "SELECT empno, ename, "+
"job, mgr, hiredate, sal, comm, deptno, ROWID "+
"FROM scott.emp FOR UPDATE";
String sqlUpdate = "UPDATE scott.emp SET comm = ? WHERE ROWID = ? ";
try {
Connection con = DriverManager.getConnection("jdbc:Oracle:oci8:@","system","manager");
// Esecuzione della SELECT e produzione del RESULT SET
Statement stmt = con.createStatement();
ResultSet rs = stmt.executeQuery(sqlSelect);
PreparedStatement ps = con.prepareStatement(sqlUpdate);
while (rs.next()) {
codice = rs.getInt(1);
cognome = rs.getString(2);
job = rs.getString(3);
manager = rs.getInt(4);
dataAss = rs.getDate(5);
salario = rs.getInt(6);
commissioni = rs.getInt(7);
reparto = rs.getInt(8);
rowid = rs.getString(9);
// Applicazione della business logic
if (reparto == 30)
{ System.out.println (cognome + " in dept= "+ reparto +
" with salary=" + salario + " has a commission= " +
commissioni);
int newcomm = 5555;
ps.setInt(1,newcomm);
ps.setString(2,rowid);
ps.executeUpdate();
else
{ System.out.println (cognome + " in dept= "+ reparto +
" with salary=" + salario + " has a commission= " + commissioni);
} // if - else
} // end while
rs.close();
ps.close();
stmt.close();
catch(Exception e)
e.printStackTrace();
} // end main()
} // end class
//PS.
//Many thanks to Bachar and Elangovan that ansewerd me to my previous posting and addressed me towards the right solution

Hi
The documentation gives following explanation for the error :
ORA-01002 fetch out of sequence
Cause: In a host language program, a FETCH call was issued out of sequence. A successful parse-and-execute call must be issued before a fetch. This can occur if an attempt was made to FETCH from an active set after all records have been fetched. This may be caused by fetching from a SELECT FOR UPDATE cursor after a commit. A PL/SQL cursor loop implicitly does fetches and may also cause this error.
Action: Parse and execute a SQL statement before attempting to fetch the data.
In your program you should set auto commit to false as follows :
con.setAutoCommit(false);
Do this before executing the SELECT FOR UPDATE sql query.
At the end of program you can commit to save the updations as follows:
con.commit();
This should solve the problem.
Chandar

List current DML in DB including SELECT for Update

In order to list all currently opened DML we can select v$open_cursor and link it to to v$SQL in order to retrieve the v$SQL.COMMAND_TYPE.
All DML operation have the following number in v$sql.command_type :
2 : 'INSERT'
6 : 'UPDATE',
7 : 'DELETE',
189 : 'MERGE'
But 'SELECT for update it is still 3 like any non regular SELECT.
I did not found information in v$lock nor in v$transaction that would allow me
to link an open cursor of type 3 (SELECT but in fact for update) to the opened transaction in v$transaction.
Does anybody knows how to assert than a SELECT is in fact a DML short of grepping the 'FOR update' in the SQL text.
Such an Horrible trick would force me to search all opened cursor text for each session with an entry in v$transaction.

Thanks for replying.
I could have had the usage of less aggressivity and more competences. You advice is simply stupid :
-- seesion 1 :
select * from toto where id = 20 for update ;
select sid from v$mystat where rownum = 1 ;   -- > sid=1614
-- session control : check v$transaction
col version new_value version noprint
col field new_value field noprint
col used_urec format 999999 head 'Undo|Records'
col undo_size head 'Undo|size (k)' justify c
set lines 150
select substr(version,1,instr(version,'.',1)-1) version from v$instance;
select decode(&version,9,'','XID,') field from dual;
Select r.segment_name,To_Char(To_Date(vt.Start_Time,'MM-DD-RR HH24:MI:SS'),'MM-DD HH24:MI:SS') strt
     , decode(vs.status,'ACTIVE',vs.last_Call_et,0) since , vs.sid, vs.status se_status,
       &field vt.status tr_status, log_io, phy_io,cr_get,cr_change, vt.used_urec, vt.used_ublk * p.value/1024 undo_size
From dba_rollback_segs dr,
       v$rollstat rs,
       v$transaction vt,
       v$session vs,
       v$process vp,
       dba_rollback_segs r,
       v$parameter p
Where vs.Paddr = vp.Addr (+) AND p.name = 'db_block_size'
   and vt.xidusn (+) = r.segment_id
   And vs.UserName Is Not Null
   And vs.Taddr Is Not Null
   And vs.Taddr = vt.Addr
   And vt.xidusn = dr.segment_id
   And vt.xidusn = rs.usn
    Order By VS.OsUser, To_Date(vt.Start_Time,'MM-DD-RR HH24:MI:SS') ;
                               Running        Session                   Transact                                                Undo    Undo
SEGMENT_NAME Start time       time (s)    SID Status   XID              Status       LOG_IO     PHY_IO     CR_GET CR_CHANGE Records size (k)
_SYSSMU21$   04-13 11:02:24          0   1614 INACTIVE 0015002A0003A800 ACTIVE            3          0        104          0       1          8
-- so we have a transaction in 1614. Let's retrieve its SQL :
-- session control : what do we have in v$session :
1 select sql_hash_value, b.sql_text sql_text, prev_hash_value , bb.sql_text prev_sql_text
2    from
3       v$session a, v$sql b, v$sql bb
4 where sid = 1614
5    and a.sql_hash_value = b.hash_value (+)
6*   and a.prev_hash_value = bb.hash_value (+)
SQL> /
SQL_HASH_VALUE SQL_TEXT                                      PREV_HASH_VALUE PREV_SQL_TEXT
             0                                                     897388722 select sid from v$mystat where rownum = 1
-- gone !
-- Conclusion : joining v$session to v$transaction is useless if you want to retrieve the SQL in system currently opened.
-- moreover, if start a transaction with many queries, you are still limited to 2 slot in v$session.

Anyone else getting a timed out error message when trying to check for updates via the app store software on a desktop?

anyone else getting a timed out error message when trying to check for updates via the app store software on a desktop?

Hi, couple of things to try...
Anonymous
Post subject: NSURLErrorDomain error -1100 in OS X 10.8
If you check for software updates using the App Store in OS X 10.8 and get "NSURLErrorDomain error -1100" the problem may be with your Software Update preferences. This is particularly likely if you were using a custom Apple Software Update server. To solve the problem, quit the App Store, move the following two files (if present) to the trash, restart, and only then rerun App Store updates:
/Library/Preferences/com.apple.SoftwareUpdate.plist
/Library/Preferences/com.apple.SoftwareUpdate.plist.lockfile
http://x704.net/bbs/viewtopic.php?f=12&t=6130
I was recently trying to upgrade to mountain lion through the app store. I have unreliable Internet from a cable company whom I will not name, but we all know who they are. My Internet dropped while downloading the upgrade. Once I went through the notorious unplug the modem/router and plugged it back in to gain Internet connectivity again, I could not resume. No matter what I did, the app store kept displaying "an error occurred." I am hoping that those with the same issue read this first to save them hours of skimming through the Internet to find a solution. Here are the steps to take:
1. Make sure you have reestablished Internet connection
2. Chances are you got frustrated when you tried to resume/unpause the download and clicked the "X" to the left. If so, select the "Store" drop-down menu from the App Store and select "View My Account." There should be an option to unhide your purchase. You know what to do.
3. There is also an option to reset all warnings for buying and downloading under "View My Account." Do this, click "Done," sign out of the App Store and quit the App Store.
4. Open the Preferences in safari and select Privacy. Select "Remove All Website Data." Just do it.
5. Launch the app store and sign in.
6. Now, if you "Check for Unfinished Downloads" everything works peachy.
I hope this helps. Not much I can do for your Internet connection though.
JonEz15...
https://discussions.apple.com/thread/4697970?tstart=120

SELECT FOR UPDATE - does it write to REDO?

Greetings folks,
we have some strange performance issues with a recent application update. This is custom in-house application. Every morning since the deploy we get a spike in load, especially to log sync / redo archive. We capture activity surrounding the load, and found many "select for update" statements.
Im digging through metalink and docs looking to confirm "write or no write" to the redo log files. comments appreciated.

sb92075 wrote:
SELECT does not generate REDO
DML generates REDO.It is possible for a SELECT to generate redo due to the effects of delayed block cleanout. A small test case:
Session 1:
CREATE TABLE T10 AS
SELECT
ROWNUM RN
FROM
DUAL
CONNECT BY
LEVEL<=1000;
UPDATE
T10
SET
RN=RN;
UPDATE
T10
SET
RN=RN;
UPDATE
T10
SET
RN=RN;
Session 2:
ALTER SYSTEM FLUSH BUFFER_CACHE;
ALTER SYSTEM FLUSH BUFFER_CACHE;
Session 1:
COMMIT;
Session 2:
SET AUTOTRACE ON STATISTICS
SELECT
FROM
T10;
1000 rows selected.
Statistics
          0 recursive calls
          0 db block gets
         73 consistent gets
          3 physical reads
        188 redo size
      11104 bytes sent via SQL*Net to client
       1060 bytes received via SQL*Net from client
         68 SQL*Net roundtrips to/from client
          0 sorts (memory)
          0 sorts (disk)
       1000 rows processedNote that the above may be performed in a single session rather than using two sessions. Essentially, the flush of the buffer cache causes the dirty blocks (containing uncommitted changes) to be written to disk, and the blocks are "cleaned up" during the next SELECT which accesses the blocks.
A much better explanation:
http://jonathanlewis.wordpress.com/2009/06/16/clean-it-up/
Charles Hooper
IT Manager/Oracle DBA
K&M Machine-Fabricating, Inc.

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.

ODBC 10.2 client makes SELECT FOR UPDATE run slower

Hi all,
I'm facing a strange problem with Oracle OBDC: I got an application which needs to connect to an Oracle DB via odbc.
Server is a 10.2.0.1; if I connect using ODBC driver installed by Oracle 8 client everything is ok but if I use ODBC driver installed by Oracle 10 client or Oracle XE client SELECT FOR UPDATE statements become really slower.
My application always does the same statement:
SELECT list_of_fields
FROM table
WHERE primary_key =
AND ...
FOR UPDATE;
If I use the Oracle 8 ODBC, this select is almost immediate; but if I use Oracle 10 ODBC it tooks ~4 seconds.
The statement is identical, so the access plan must be the same.
The ODBC configuration is identical too; tnsnames.ora entries are the same.
So, why the 10x clients are slower?
thanks for every answer
andrea
Message was edited by:
user585511
Message was edited by:
user585511

Which cursor library are you using? The ODBC Driver Manager's cursor library strips off the FOR UPDATE silently (see Appendix F of the ODBC Programmer's Reference). Depending on what version of the "Oracle 8 client" you were using, there may not have been an ODBC driver cursor library, so you may have been forced to use the driver manager's. Potentially, the slowdown is that you're now actually locking the rows now and may be running some contention issues.
It would be worthwhile to trace the sessions and see what the difference in waits is.
Justin

How to avoid 'select for update'

Hi,
we are using the bc4j framework of jdev 3.2.3. We have a View which collects data from several tables in different database schemes, so we naturally have to use the 'union clause'. But if we try to make an update on a row (via 'setAttribute'), we got a DMLException ORA-02014 telling us that we should not use 'select for update' on views whith unions.
Since i cannot avoid using a union clause, is there a way to avoid the 'select for update' in the bc4j framework?
Please help, its urgent!
Thanx,
Dietmar

SELECT FOR UPDATE is used for our implementation or row-level locking.
If you are using pessimistic locking mode, this will occur the first time any attribute is modified.
If you are using optimistic locking mode, it will be deferred until post/commit time.
If you are using "none" locking mode, it will not happen in your application may hang indefinitely if another session has locked the row.
Are you asking how to avoid locking?
Do you mean to be updating this view with a union over multiple databases?

Error message: "playlists selected for updating no longer exist"

I tried to update my ipod nano and I guess I had deleted a playlist, but since then, I have not been able to update. Every time I try, I get the following message:
"Cannot be updated because all of the playlists selected for updating no longer exist."
I haven't been able to highlight which playlists are selected to begin with.
I read through the manual and thought that maybe rebooting the whole system might work. So I deleted Itunes from my computer and re-installed.
Then I tried re-setting my ipod. So now I have nothing on my ipod.
I also deleted everything from my library, thinking it might help to start from scratch. Nothing has worked.
How do I "select" and "unselect" playlists so I can get up and running again?

Here you go.
http://discussions.apple.com/thread.jspa?messageID=607312&#607312

Lost music on ipod because "playlists selected for updating no longer exist

Not sure what I've done. I recently downloaded newer version of itunes. Then when synching, I had too much music in my library for the ipod to handle so it told me about doing the smart playlist. I erased a couple of playlists on the itunes menu I no longer wanted and then when I went to synch, this error came up "songs on the ipod cannot be updated because all of the playlists selected for updating no longer exist."
Please help.....

Check this out.
iPod cannot sync because one or more playlist....

"All of the Playlists Selected for Updating No Longer Exist"

My family has 2 ipod shuffles. After purchasing a Nano recently, I inserted the cd that came with it. Apparently the existing iTunes software was removed and reinstalled. At any rate, the library still shows all the original songs, but when the Nano is plugged in, iTunes immediately gives a prompt stating "Songs on the iPod *** cannot be updated because all of the playlists selected for updating no longer exist." The library is there, the playlists that were there are there, and I can play the songs on my cpu. Is there anything I can do besides completely uninstalling everything and starting over?
iPod Nano Windows XP Pro

This user tip should help you sort out your missing playlist problem: Hudgie - iPod cannot sync because one or more playlists are missing

"Playlists selected for updating no longer exist"?!

everytime i plug my ipod mini into the computer, a pop up appears saying that the playlists selected for updating no longer exist!!! it's done this before, so i completely restored the setting and made a whole new library. now it's doing it again. i have all the playlists and songs on my computer in a folder. all the songs that were on my ipod, got deleted when i plugged it into the computer. so my ipod is blank, but i have the songs in my library still. they just wont upload. any help would be greatly appreciated....

Check this out.
iPod cannot sync because one or more playlist....

SELECT FOR UPDATE via KODO queries

Similar Messages

Maybe you are looking for