cancel
Showing results for 
Search instead for 
Did you mean: 

A newer version of data type SNAP was found than one required

indrajith_v
Participant
0 Kudos
1,733

Hello All,

We had recenlty migrated the ECC system from HP-UX to Linux. After succesfull import.. we had a requirement to import a single table after the import we are facing issue on target system . we cannot run the tocdes : St22,Sm37,sm21,sm20,sm51,sm66,se38. for every tcode we ran is routing to the same dump screen as attached.

We also not able to initiate the SGEN, please help.

We did tried by chaning the Kernel,shutdown and startup completelty.nothig worked.

Accepted Solutions (1)

Accepted Solutions (1)

sconicelli
Newcomer

We need to regenerate all of the programs. I was able to fix this issue by running transaction code SAMT. We could not start SGEN because that transaction was also affected by the error.

  1. Run tcode SAMT.
  2. Double click on the Generate program line item.
  3. Click on the "Create" button in order to create a new program set.
  4. Enter a short description.
  5. Enter programs to be included in the program set.
  6. These programs should be found by investigating the latest dev_w* logs in the work directory.
  7. Once back on the main screen, click on the newly created task once and then click on the "Task" executable button.
  8. Once the SNAP table issue gets resolved, you will now start getting "normal" ABAP dumps. These dumps will have clues as to which programs need to be activated next. For example, if you want to get SM61 working again, try starting that tcode. You will get an ABAP dump showing which program is the culprit. Try activating that program using the above process. For certain ones, I would add multiple programs to the program set. For example, CL_WB*, CL_GUI*, CL_SALV*, CL_ALV*, etc...
  9. With some repetition of the above process, I was able to eventually manually generate enough programs to get us back to SM61.
  10. We added our app servers and then started SGEN.
  11. SGEN is still running now...

Thanks,
Steve

indrajith_v
Participant
0 Kudos

Thanks Steve

Answers (6)

Answers (6)

S_Sriram
Active Contributor
0 Kudos

Hi Indrajith.

You have to check the SAP kernel & DBSL patch levels based on your target system. if possible upgrade the latest kernel level and then check the system.

Regards

Sriram

S_Sriram
Active Contributor
0 Kudos

Hi Indra.

During the system migration(System copy ) have you used the same version of media's? Could you share the version details in source and target systems?

BR

SS

indrajith_v
Participant
0 Kudos

Thanks!!!

JAVA COMPONENT : 51048184

SAP:NETWEAVER:701SR1:DVD_EXPORT:SAP NetWeaver 700 EHP 1 SR1 Installation Export DVD 1/1:D51036859

SAP:AKK:721_EXT:DVD_KERNEL:SAP Kernel 721_EXT:Dxxxxxxxx:*:D51051179

SWPM :

70SWPM10SP18

oracle :

ORACLE:12.1:RDBMS:Oracle RDBMS 12.1.0.2 for Linux X86_64 DVD:LINUX_X86_64:LINUXX86_64:D51047708

Let me know if any thing else is needed.

yakcinar
Active Contributor
0 Kudos

Hello Indrajith,

I think there is no disk or datafile related issues.

Is there any error messages on SM21?

Regards,

Yuksel AKCINAR

indrajith_v
Participant
0 Kudos

we could not access the SM21 it is giving us the same Dump screen as mentioned above.

S_Sriram
Active Contributor
0 Kudos

Hi Indrajith

Execute the transaction SICK. check any error message ?

regards

SS

indrajith_v
Participant
0 Kudos

SICK has no Errors.

raymond_giuseppi
Active Contributor
0 Kudos

The problem may not be related to table SNAP but to any, many, every table(s) in your copy, as the new version of snap is detected only when system try to generate a dump, basically you get a dump declaring that it's no longer possible to generate a dump hiding the original error...

Was SNAP the table mentioned in 'we had a requirement to import a single table', are you able to display its import log from original system?

Regards,
Raymond

indrajith_v
Participant
0 Kudos

Thanks for your reply.
After the Successful System Copy.(all packages were imported Successfully)
We had a requirement to import the only one table "EDI40": from Source . (we are not sure whether the issue is due to this EDI40 table import)

please help to solve this error.

Thanks in advance

Matt_Fraser
Active Contributor
0 Kudos

So just to be clear, the system was working fine immediately after the system copy, no problems, but then after importing the single table EDI40 all these problems began. Is that correct? If so, it would indeed seem that this single table import is the likely cause of the error. When you say that you imported a single table, what exactly do you mean? How did you do this? Also, can you revert to a backup taken after the system copy but before the EDI40 import?

Cheers,
Matt

yakcinar
Active Contributor
0 Kudos

Hello Indrajith,

Try activating SNAP table using SE11 or SE14.

And if programs get dumps activate them individually from SE38.

Then try running SGEN.

This will resolve your issue.

Regards,

Yuksel AKCINAR

indrajith_v
Participant
0 Kudos

Hello Thanks for your reply.

Yes we did try running the SGEN . unfortunatelly the Job which gets triggerred is being sent to scheduled state . and we cannot move it to active since we were not able to access Sm37/Se38 .



and also tried activating the table from SE14 . but on clicking on the activate button the below screen appears again .