ALV field in RIMARA20 program is missing after migration to S4HANA - abap

I have the following issue.
In the past, we have added some fields to transaction IH09.
However last year we migrated to HANA and a lot of programs were updated in the process including the program RIMARA20, which is the program behind IH09.
IH09 has worked fine with the added fields were seen.
Last week I was asked to add another field and I did it however although the field catalog has the new field, it is not shown in the output of IH09.
I have debugged the code countless times trying to figure out what is going on but I don't know what happens.
This program internally uses the function REUSE_ALV_GRID_DISPLAY.
We still have the former SAP environment and I tried to make exactly the same enhancement with this new field and I can see it as expected.
In other words; the same field, the same data element, and the same enhancement in both environments but in the HANA instance I cannot see it.
I'm truly frustrated because I see the new field in the field catalog but I can't make it visible in the report.
Any advice on this issue?

Sounds like the REUSE_ALV_GRID_DISPLAY has "remembered" the old catalog
Did you try
to reset the layout / add the missing field?

Related

Access Form switches unintentionally between Datasets

I am rather new to coding an Access Application and I have a rather strange error I do not seem to be able to resolve.
I have multiple Forms which are used to write data to some tables. Basically one Form per table.
Mostly the forms are just used to show a selection of the data in the tables. To make sure that noone accidentally alters some data you have to press the button "alter" first, which unlocks the fields to alter the dataset. In one form, however, when you ppress the alter button it switches the dataset. I have one column which is an automated ID which serves as a primary key to distinguish the data from one another.
So when I am debugging the issue and print this ID (Debug.Print Forms(formName).Controls("ID")) it returns the ID of the data that I want to alter, but as soon as I access the data and change one field (Forms(formName).Controls("Column1") = "foo") and print the ID again the ID switched to a completely different dataset.
I have absolutely no clue how that could happen. There is no other code being processed in between. I have googled for multiple hours but have not found anything in this regard yet. Maybe I am just using not the right keywords.
Any help is highly appreciated.
Thanks in advance :)

Podio Calculation field issue

We have an issue with a calculation field not always working. (We have about 5 calculation fields that are similar so same applies to all).
See in the attached example.
The Textbook item has a calc field 'Set Text'. One of the values in there is showing 'Null'.
Most of the time this works fine but in about 8% of the cases it has this null error.
See the other screenshot of the Aggregator item. The field that is being referenced there is correct.
To fix it we have to manually remove the relationship between the two items and then put it back again, to force the calculation to recalculate. This fixes the issue. So the problem does not seem to be the formula but rather the calculation being performed incorrectly.
The Aggregator items are created and joined to the Textbook item through the API.
This is a big issue for us as we use this value to post to our website so the manual fix is not a practical solution.
Podio support please advice what the issue is here
Aggregator
Null error
Without knowing too many details about your specific workflow and structure, let me offer some ideas:
Podio calculation fields can begin to act in strange ways if the original field is being referenced by calculation fields too many levels deep. What I mean by this is that if the original field that shows the Paper Code (or whatever that int showing null is) is being referenced through too many calculation fields, it can begin to cause problems in cases of updating and adding new items. This is most definitely a bug I've encountered with large-scale systems, but there are workarounds.
First off, I see that you have all of the pertinent non-concatenated fields at the bottom of your Aggregator app. Try manually concatenating those fields in the Textbooks app (where you're doing the result.push) instead of referencing the Web course text calc field exclusively.
If that doesn't work and you're proficient with the API, a longer workaround could be that after the automation runs, you wait a sufficient time (say 30 seconds) until the calculation field updates, have the API check for the text "null" in the calculation field, and refreshes the relationship fields if null is found.

Table Adapter not updating after adding parameter

I'm quite new to .NET and very new to TableAdapters. I am currently working on updating an existing program and am required to alter some SQL code to update a field in one of the databases where I work. I've changed my VB and code and everything in terms of my UI is good to go so I am now trying to update the TableAdapter that is used to account for my change.
I am adding a parameter (#jobNumber) and wish to update the field 'DISCRETE_JOB' in the database table I'm working in.
I've added in the 'DISCRETE_JOB' parameter to my INSERT INTO statement as the third parameter and added the '#jobNumber' as the third parameter in the VALUES() line of my SQL.
After Finishing the changes are there when I bring up the tool-tip (by hovering mouse over the TableAdapter Query) but the actual parameters listed beside the name of the Query int the DataSet.xsd file are not updated
Looks like-> InsertData(#Param1,#Param2,#Param3)
Should look like -> InsertData(#Param1, #Param2, #jobNumber, #Param3)
Even after saving changes to the .xsd file the parameters don't SHOW the changes of parameters. I also took a look at the DataSet.Designer.vb file for the DataSet.xsd file and it doesn't appear that my new parameter has been taken into account.
Again, I am new and there may be a couple of things I'm supposed to do to make these changes happen, but I just don't want to mess anything up, as there's a lot of queries in the file for this program.
Thanks! Let me know if I need to provide more detail.
UPDATE: I fixed my problem, though I'm still not sure exactly what was going on and why the parameters weren't updated automatically.
Here's the fix:
The SQL code I added remained in place, but I needed to manually add the parameter I wanted. To do this I went to the properties of the query in question and clicked 'Add', filling in the correct fields based on what the existing parameters looked like as a guide line.
Hopefully this can help someone else too!

Any ALV-specifics with itab created by RTTS?

I create internal table by two steps, both refer to the RTTS-techniques.
The first step loads and parses a tab-delimited file into a table.
The second step reads this table by RTTI, then, hardcoded, adds some other columns in front of the old columns from the file and, finally adds the old fields back again, the table now has about 12 new hardcoded columns, in front of those from the file. The RTTS helps to create the final table, which then is passed as the data source to the ALV grid.
My former requirement did not take into account that the ALV-grid-toolbar-functions will ever be needed by the end-user, however, as always, this has changed. I enabled the toolbar functions, the default ones, without any custom button.
So, now the user can remove some columns from the display or add them back again, she/he can also change their order. Everything is fine but I never encountered this situation with a table, which is created during runtime.
Are there special culprits I need to be aware of ?
<ITAB> created using RTTS functionality is fully supported either by the REUSE_ALV_LIST_DISPLAY or one of ALV OOPS technologies. All the layouts should work fine. In fact I think in the cl_salv_table=>factory RTTS is responsible for automatic creation of the field catalog of the ITAB since it do not need field catalog passed by the parameter. The only thing that I heard is lost pointers of the <ITAB> ant this leads to refresh problems and so on but this is different story.
From my experience, ALV column maximum size is 120 characters. So if your file could have more than that, you could have a problem. Otherwise, do not expect any major thing.

SQL Server Reporting Studio report showing "ERROR#" or invalid data type error

I struggled with this issue for too long before finally tracking down how to avoid/fix it. It seems like something that should be on StackOverflow for the benefit of others.
I had an SSRS report where the query worked fine and displayed the string results I expected. However, when I tried to add that field to the report, it kept showing "ERROR#". I was eventually able to find a little bit more info:
The Value expression used in [textbox] returned a data type that is
not valid.
But, I knew my data was valid.
Found the answer here.
Basically, it's a problem with caching and you need to delete the ".data" file that is created in the same directory as your report. Some also suggested copying the query/report to a new report, but that appears to be the hard way to achieve the same thing. I deleted the .data file for the report I was having trouble with and it immediately started working as-expected.
After you preview the report, click the refresh button on the report and it will pull the data again creating an updated rdl.data file.
Another solution to this issue is to click Refresh Fields in the Dataset Properties menu.
This will update the list of fields, and force SSRS to get new data, rather than relying on a cached version.