So, short version is that if there's anything you need to store outside an individual function call in Decker, the intended solution is to store it in a widget, on a card. Values of variables otherwise don't persist outside the specific piece of code that you're running at the time.
Let's say if you need to store a string named "mystring", you'll probably want to make a field widget to store it in, let's say it's called field1. Then in your code you can just store it like this
field1.text:mystring
And you can then access field1 from any other bit of code on the same card and retrieve the string from field1.text. And if you don't want the user messing with it at runtime, you can "lock" the widget or set its view attribute to "none" to hide it.
If your widget is on a different card, that's no problem either. I find it can work to have an inaccessible "utility" type card for holding onto variables. Let's say if I have field1 on a card named "myvars" for example, I can refer to it like this
myvars.widgets.field1.text
If you're storing values other than strings, in theory pretty much every Decker datatype can be serialised into a string but it might make more sense to use other methods for different data, depending on what you want to do. There's a bit of information in Phinxel's Field Notes, in the Lil section on the "Storing Information" page that might come in handy here.
It sounds like you've tried something like this but run into some issues, maybe you could go into details? In theory even if you're doing something "wrong" Decker shouldn't be hard-crashing so if you've got some examples of that then that could be handy in case there's a bug.
If you want to have a global constant though, that's a bit of an easier matter. You can at the top of a widget script, or a card script or the deck script, predefine the values of variables to essentially use them like global constants. Something like this
magicnum:1234 mystring:"Hello, World!"
I hope this makes sense but let me know if you need more explanation.