Hello proudpoppy,

To initialize the GlobalValue just run a single record Mass Update with the following code.

GlobalValue("NextCustRecNo", @Str(1518))
 

What did not work for you?

Proudpoppy,

Run the code in a Mass Update to set it the first time. Retrieve one record and run a Mass Update that sets the starting number. You don't need to save the Mass Update or ever run it again. You do, however, want to run the Mass Update from Preview in Designer to get it into the dsr. Otherwise, your Global Value will be reset when you Reconcile.

If you are using Global Values, you should be aware that Reconcile will reset them to the current values in the dsr. Before making design changes, you should make a new dsr out of your db so you have these values.

Bob, I completely agree with you.

Currently I have a sticky note that I stick on the wall next to my desk whenever I am 'designing' and anything a user saved in the Spec Manager in the DB will be lost when I reconcile.

Its very confusing and cumbersome. Its just a matter of time before someone loses something of importance.

Hopefully there will be a solution soon.

Steve

As Erika stated, we are going to put an option in reconcile to either reset or retain reconciled values. The problem (looking into the future) with this approach is that it will still only cover a portion of what people are trying to do at any given moment. Today we have users who always want to reset all their Global Values, and we have users that always want to retain all their Global Values. But as designs progress, we will have more and more users that will wish to retain some, reset others, delete and recreate still more.

The two current "camps" depend on whether your way of working is driven by the .db/.dat file or the .dsr/.ddt combination. Some people keep the .db/.dat files - not the .dsr/.ddt and always regenerate .dsr/.ddt before making design changes. Others do the reverse. There are a number of designs that use the GlobalValues as a kind of ongoing lookup. Others *need* to have them reset as part of a design change. I have an application that uses the GlobalValues as derived from the Zip Code database, replacing it completely. The number of variations of use is endless. For those that are using Global Values simply as a @number replacement, and the numbers generated are contininous and ongoing, then yes - it is necessary to derive those numbers from the running .db file. A simple one record mass update will do the trick before a reconcile.

In the long run, it comes down to how much control you want. The way it works now, the value of a Global Value is applied at design time by the designer of the application. If it were always derived from the .db at reconcile it would always be decided by the actions of end user (appropriate in the @number case (given there have no mistakes on their part), but not  many others), if it were a single setting: "retain Global Values" at reconcile, then the question would be: "which Global Values" because some might be altered or reset at design time, and runtime Global Values would begin to inappropriately accumulate. The complaint would become that there is no way to reset the value, as opposed to it being "cumbersome" to retain the value. Additionally, if we offer to let you set/reset them one by one at design time, we certainly limit the extremely useful option of having many thousands of them, in that it would be extremely cumbersome to have reset or retain them individually were there more than a few. They would have to be "classed" upon creation: some being reset at redeploy, others being retained at redeploy. Or, by some means, queried and grouped.

Looking a few steps further down the road, the most flexible solution is to provide yourself with a simple mass update that derives any ongoing Global Values from the fields driven thereby, and use that mass update either before a reconcile, or after, depending on requirement. That way you have a flexible means, that adapts to the design addition of a further Global Values, that can selectively reset or retain values, that is far less cumbersome than a (possibly) lengthy dialog box with at a bare minimum of one button and one text box per GV.

By being a mass update, it can easily be checked for correctness and completeness, can easily be undone, should there be a mistake, can be printed, retained, edited in a text editor, and supplied to end customers, without sacrificing design control. And, given, that these would not change with every design change, this program only need be written once, checked for correctness once, as opposed to redecided every time a reconcile is invoked.

So while this solution does require that the application programmer have some programing skills, these must already be present for Global Value use in the first place. A less flexible, but more structured solution is to use "data driven" programming. That would mean checking the Global Value before use for a "reset value" that indicates that the Global Value needs to be rederived before use (if appropriate). That approach (in general) guarantees correctness. It does mean that you have to have the discipline when writing code to check for initialization before use. But given that we (Lantica developers) cannot tell if your application falls in the "reset camp" or the "retain camp" or in the ever-growing "mix-n-match camp", such an approach is probably worth the additional effort to adopt. It will make your application easier to maintain, more flexible, and more deployable.

Afterall, there are many uses for Global Values:

1. A retained value that can be altered at runtime
2. A communications channel across users and across time
3. A logging mechanism
4. A unique number generator
5. A field supplement
6. A static/dynamic lookup table
7. A simple lingual translator
8. A generational marker or tag
9. A copy control mechanism
10. A secondary security scheme
11. A replacement for "hard coded" values in SBasic
12. A multilayer undo
13. Result set retention
14. Legal shell command contents (offer choices, but *all* choices)

etc....

Some of these wouild benefit from a reset, others would want to be retained. Some are so dynamic it hardly matters.

Quote:


Objections? Of course not. We'd be interested to hear what you come up with.

Just as a side note, the next release will have some new features that should make you developer-types pretty excited... 8)

I would not be surprised to find that MOST design changes will not be done while the users are stopped from using the application.  Data entry will continue and the changes will be made on a DSR until it is convenient to do another Reconcile.   (Since 78.3% of all statistics are made up, then I cannot defend the use of MOST, but do feel comfortable that I may be correct).

And then we have the poor individual (self designer/ outside developer) who has no personal history of how/why these are used in a particular application.  The internal self designer is on vacation, or leaves and is replaced.  Or the outside developer inherits an application was originally designed by someone else.  Worse, that someone else is not available for helping. 
How do they make the decisions about what should be reset and what should not be reset? How to do a correct Reconcile?

And let's not forget that most of the discussion today is about Global Values, but we still have the issue of different Saved Specs in the DAT and the DSR versions.

Even with defined steps we are depending on a person to do ALL of the steps, in the correct order, without error.  That is just asking to have it done wrong.  The current method:  Select the DB to be reconciled and click OK is the correct way for us to do this. 

All the supporting tasks need to be built into the process under the covers.  I would have no problem if I am prompted on each set of Saved Specs/GlobalValues to reset to 0 or some other value, to keep values in DAT or values in DSR?  Or these decisions could be predefined in a an internal table as some type of property associated with each object.  Example:
Saved Specs1:  Prompt for each/Use DAT/Use DSR
Saved Specs2:  Prompt for each/Use DAT/Use DSR
GlobalValue1: Prompt for reset value (0=default)/Use DAT/Use DSR
GlobalValue2: Prompt for reset value(0 = default)/Use DAT/Use DSR
These values would be maintained in a database in the DB and used at the time of Reconcile.  Reoncile would prompt to accept values in internal database, or review all values and reset them also.

As a help to ourselves, we are all probably using our own naming conventions.  Maybe a different naming style for the Global Values would help.  I suspect that I will start to modify my naming to ID those GlobalValues that need to be maintained during Reconcile, and those that need to be reset.  At least that should make it easier when it comes time to follow the manual steps needed now.

Along that line, perhaps the GlobalValues themselves could become different types if that would make the reconcile process more accurate and error free,

I am glad we are having this discussion, but it is important to remember that we can accept some "inconvenience" and we can take the extra steps,  The real potential problem is the potential of bad data.  Until Sesame can do this by itself, I would still like to see a step by step process defined, in proper sequence, listing the things to be done to incorporate a DSR into correct sync with a newer DAT that will truly RECONCILE all of the GlobalValues, Saved Specs, etc. into a new DAT. 

Enuf ideas for now, gotta get back to work.......

Quote:


That may be correct for your particular situation, but it does not apply universally. It depends on what the global value is being used for.

There is a function GlobalValue(nextrecordnumber, "1517") which does exactly what you suggest with @resetglobalvalue.