Cikk mentésekor hiba

Sajnos ugyanazt, amit eddig.

Azon is gondolkoztam, hogy az adatbázissal lehet valami probléma?

Bár akkor a Bővítménykezelő->Adatbázisnál kellett volna valami hibát talán írnia.
Az az érdekes, hogy mindent tudok, csak a cikkeket módosítani és újakat felvenni nem.

Ez inkább olyan tünet mintha, nem lenne hozzá jogosultságod. Cikk-kezelő beállításai -> Super Users engedélyei?

Sajnos (?) minden engedély megvan a cikk kezelő szerint

|– Super Users
Művelet Új beállítás 1 Kiszámított beállítás 2
Konfigurálás Engedélyezett (főadminisztrátor)
Hozzáférés komponenshez Engedélyezett (főadminisztrátor)
Létrehozás Engedélyezett (főadminisztrátor)
Törlés Engedélyezett (főadminisztrátor)
Szerkesztés Engedélyezett (főadminisztrátor)
Állapot módosítása Engedélyezett (főadminisztrátor)
Saját tartalom módosítása Engedélyezett (főadminisztrátor)

Na most már végképp nem tudom, hogy mi lehet a baj...

Az alap (1.5-ös Joomlán) hibátlanul tudok menteni is.
(Ugye az alaprendszer megvan, mert most a /jupgrade mappában van a 2.5 és az adatbázisban is megvannak a táblái az 1.5-nek jos_ prefixel)

Megpróbáltam, hogy onnan kimentettem a content táblát és a 2.5 alól is, majd a mezőszerkezetet az 1.5 dumpban átalakítottam, hogy megfeleljen a 2.5-nek, hátha a migráció során lett valami baj. De ez után sem javult meg a dolog miután visszatöltöttem az 1.5-ös dumpot a 2.5 alá.

Utána még azt is kipróbáltam, hogy localhostra telepítettem egy teljesen tiszta 2.5-t és ott tudtam menteni cikket! Ezután kidumpoltam ezt a content táblát, majd visszatöltöttem a szerveren lévő élesítendő 2.5-re. Az a cikk benne is van, amit a localhoston hoztam létre, de így sem tudom sem módosítani, sem újat létrehozni...

MOD:
Közben újabb turpisságra jöttem rá. Van a joomla gyökerében egy logs mappa, ami tartalmaz egy jcontroller.log.php állományt. Arra figyeltem fel, hogy ha az 1.5-ös joomlán változtatok valamit a cikkben, ahol sikerül, ott ez a file (jcontroller.log.php) nem változik. A 2.5-ön, ahol nem megy a cikk változtatása, viszont igen! Ez kerül bele, mintha az ID-val lenne valami nyűgje. Úgy tűnik, hogy valami 3060 és 3066 közötti eltérés lehet... Az utolsó cikk id-ja valóban 3060. De mi lehet az a 3066?

2013-01-26T23:54:27+00:00 INFO controller Releasing edit ID com_content.edit.article.1 Array ( [0] => 3066 )
2013-01-26T23:54:35+00:00 INFO controller Holding edit ID com_content.edit.article.3060 Array ( [0] => 3066 [1] => 3060 )
2013-01-26T23:54:35+00:00 INFO controller Checking edit ID com_content.edit.article.3060: 1 Array ( [0] => 3066 [1] => 3060 )
2013-01-26T23:54:38+00:00 INFO controller Checking edit ID com_content.edit.article.3060: 1 Array ( [0] => 3066 [1] => 3060 )
2013-01-26T23:54:38+00:00 INFO controller Checking edit ID com_content.edit.article.3060: 1 Array ( [0] => 3066 [1] => 3060 )

Na mára már elég lesz a felfedezésből...

Megnéztem, és 3066 érték 1 helyen szerepel a content táblában, az asset_id mezőben van, a 3046. id-s cikknél! Tehát az asset_id mező látszólag a cikk id+20 értéket kap.
De ami a fura. Kipróbáltam, hogy a localhostra töltöttem vissza az "éles" 2.5-ös adatbázist, hogy kiderüljön, a tábla jó-e, mert ugye localhoston megy a mentés... Vissza is töltöttem, és az utolsó cikket sikerült is mentenem. De ekkor jött a meglepetés, annak a cikknek az id-ja volt a 3060, az asset_id-ja pedig 3080. Viszont miután el tudtam menteni az asset_id 3080-ról megváltozott 38-ra!!
Létrehoztam egy új cikket, annak az id-ja 3061 lett, viszont az asset_id-ja csak 39!!
Tehát úgy tűnik, hogy valamiért a migrálásnál rossz lett az asset_id érték és ezért nem tudja menteni?
Viszont, ha a localhoston átírja mentéskor, mert rossz az érték, miért nem írja át a szerveren? Ellenőriztem, és a db usernek all privileges joga van az adatbázisra.

Már az egészet nem értem...

Vesd össze két ugyanolyan cikknek az ID-ját, egyezik?