Variable names inside LET function are prefixed with _xlpm

So this file was a .xlsx file before I changed it to .ods after migrating to Linux.

I tried using variables inside a Let function on a clean file. For some reason, this is the only file that keeps prefixing the variable names with _xlpm upon re-opening it. What could be the reason, and how can I resolve this?

  1. Open the file.
  2. Delete everything from it.
  3. Create a LET formula in it.
  4. Save and reload.
  5. Check if it still fails.
  6. If it doesn’t, try to find out, deleting what heals it.
  7. If it does, attach it here for inspection.

I deleted all of the sheets in the file, but the problem still persists. Maybe there’s still a VBA macro but I don’t know how I can remove it. I don’t see anything in Tools > Macros > Organize Macros (Basic, BeanShell, Javascript, Python).

I saved it as .ods already

Do you mean, that you missed the point 7 in my advice?

1 Like

I was only at point 6.

Is “a” a reserved word or some sort?

A is the name of the first column.

I just changed the variable from a to b and it doesn’t prefix the variable with _xlpm anymore. Probably a variable is being used somewhere is the file. Same with the data variable

Unfortunately, you ignored the point 7, and thus this topic can’t help anyone, because we couldn’t analyze the problem, diagnose it, and maybe suggest other solutions or fix. We couldn’t even improve wording for this still-unknown problem, to help people find it.

1 Like

Probably there’s still fragments from Excel left. I just created another file and redo it.

Sigh. You found a workaround, and solved your local problem. But you decided to not help us improve. If we had that file, we could try to fix Calc, so that it doesn’t create problems with “fragments from Excel left” - not being able to see the problem means others will continue to suffer.

1 Like

They may not be able to share the file. Maybe it contains sensitive data which they can’t release, and they can’t reproduce the problem with other non-sensitive data such that the underlying problem can be determined. Unfortunately, this is very possible if dealing with things like medical records, financial information, government data, etc. I definitely understand that it is frustrating from a development standpoint (as I have experience it directly from a support standpoint), but sometimes people simply can not share what would be most useful for a developer. Perhaps a better approach would be to offer to create a debug version of the app which targets the particular area the problem concerns and ask the person to run that version on their data and report back what they find, giving them the option to scrub out anything which might be not-for-everyone’s-eyes. That would at least allow some level of troubleshooting data to be shared.

There is a thing named communication. If there’s such a problem, people tell so. They usually don’t need third party advocates explaining those things to stupid developers.

2 Likes