Something else must be going on Mark. I can't reproduce that problem.
Agree with Ralph. Something else is wrong.
- The correct syntax is: GetNextSerialValue ( "filename" ; "tablename::fieldname" ) Make sure you wrap them on quotes as shown. You don't need the file extension.
- You dont need records on a table to have access to that value.
- Whether the field type is Number o Text, you will get all whatever value is in that field's Serail Number next value section.
Hope this helps,
I forgot to mention one crucial piece of information. This is running on a Windows 7 64 bit system. Do you suppose the "something else" could be Windows vs Mac?
Best regards, Mark
From what I understand, the table is empty (zero records). If that is the case then a null response is to be expected since there are no records available. Have you tried the command in a script while running the debugger? My guess is you would get a record missing error.
The Next Serial Value does not rely on the records on a table.
Maybe your file is read only?
Can you post the file so I can debug for you?
When I use the GetNextSerialValue design function on a file with a serial field greater than 1, all is fine. However, if the field's next serial value is set to 1, GetNextSerialValue returns a null (nothing). I would think it would return a 1. Granted, a next serial value of 1 would imply that there are no records in the file, but 1 is still a real value. Is my logic off?
For the GetNextSerialValue function to work after it's first set up and initially working, there are a couple of things which could cause it to stop working. Such as if you change the name of the field, or the name of the file (unless you're using the get(filename) function within). Or if you change the field to say a Date type or other incompatible field type.
But that's it. I can't see any other reason why it wouldn't continue to work. Even if the Table has no records, it doesn't matter. For example, making a clone of a file doesn't change the internal register of what that next serial number is going to be...
Setting a field's next serial value to 1 always works for me. I wonder if you are altering any other field-definition setting when you do reset it to 1?
Via script there should be no issue. But if you have no records and you have defined a calculation then the result will be null because a calculation needs a record to evaluate.
Avoid hard-coding file nd field names.
Assuming the field is in the current file then use:
GetNextSerialValue ( get( filename ) ; GetFieldName( tablename::fieldname ) )
Thanks for the ideas. The strange thing is that this is controlled via a script where I'm setting a variable with this calculation: Set Variable [$SerialValue; Value:GetNextSerialValue ( $SerialFile; "@Instructor::_pk_Instructor ID")]. The $SerialFile is set to a constant value "HTA OLD". So without changing anything in the script and working with the _pk_Instructor ID auto-enter Serial number, when it is set to 1, the $SerialValue variable is not defined. When I change the _pk_Instructor ID auto-enter Serial number to anything other than 1, I get that next serial number back in the $SerialValue variable. Also, there are records in the table. So, since the only thing I am changing is the value contained in the Auto-enter serial number, all other possible problems such as renamed fields and various calculations are eliminated from the test. So, I'm still baffelled. Since Ralph could not duplicate the problem, I am still wondering if this is a Windows issue.
Best regards, Mark
Since we've covered many possibilities about naming consistency, one other possible requirement is that the file being tested is actually open. And that it's name (without its filename extension) is still actually "HTA OLD" under Windows as it is under Mac.
I am still wondering if this is a Windows issue.
Can you repeat the test on a Mac; if so is the problem still there?
Sorry Ralph, I only have access to my Windows PCs. The file/table being checked is open. If whether it is open or closed might explain the situation where nothing came back. Here, everything works fine when I set the next serial value to greater than 1. I'm giving up on this one. I think I can create a workaround. The table I'm checking is a temporary table (records are deleted after its use). So instead of getting the next serial number, I'm going to just set it to 1 and be done. At least that part works.
Thanks again for the thoughts,