I am working on a database where the client requested the ability to see and change the next serial value of ID fields. However when I tried to use the GetNextSerialValue function only to find it wasn't returning anything. At about the point I was ready to throw my computer I discovered that it worked on another database I had on my server. So I put the client's file on my server and it worked no problem. Does anyone know why that might be? Is there any way to make it work either way? The database won't be on a server at all of the client's locations.

It is much more likely that you simply were not using the function correctly. Field was not defined as a serial number field, not quoting the field name or using getFieldName function, or something else. Can you post a clone of your file?

Like I said, I put it on the server and it worked fine. No changes. I has quotes around the field name and it is a serial number field. I read all the other posts about this function and none of them apply. It is the weirdest thing...

Well, something is missing in your description or testing; because it does not need to be on the server to work properly.

I am working on a database where the client requested the ability to see and change the next serial value of ID fields.

This is one of the most dangerous things I have ever heard. Do you realize that changing the ID could cause non-related records to suddenly relate? Do you realize that the IDs should never change?

More importantly, does your client? I doubt very much that they have any idea about the importance of unique auto-enter IDs and what would happen if they get it wrong. To provide them with the ability to change IDs is like handing them dynamite.

To provide them with the ability to change IDs is like handing them dynamite.

I think you misinterpreted the original request. It is not about changing IDs on existing records (which is indeed scary). It is about changing the "next serial ID", i.e. the ID that will be auto-assigned to the next record (yet to be created).

Presumably there will be safeguards so that the user's ability to choose the next serial ID will still maintain the database integrity. For example the user may be allowed to advance the ID past a range of values. This should be safe enough because the user can already do this by simply creating and deleting records (or lacking the ability to delete, create and not use those records).

Edited October 19, 201015 yr by Guest

I am with LaRetta on this one. I allow users to change their serial reference but they never get to see the serial reference used by the system much less change it

Phil

HEY INK!! Good to see you around again, Phil!!!

And yes, it would be okay if they advance the serial way ahead but why would they want to. The only reason they would really want to change the serial is to start it over; regardless, one mistake on entering that number and ... of course if all the child records go orphan, they'll need to call a developer to fix it.

However, a process should be available if cloning an empty file (or deleting all records) and the need to start over. But if there are related records that wouldn't be simple either without scripting it full. Sorry, but I simply wouldn't open it.

Well, something is missing in your description or testing; because it does not need to be on the server to work properly.

That's the strange thing, I literally took the file I was working on, put it on the server and everything worked. I tried the file not on the server again and it didn't work (no changes were made to anything). I even tried a backup file my server made of the working file and it didn't work. I tried this both in a calculation showing the result in a Custom Dialogue and in a calculation field.

I think you misinterpreted the original request. It is not about changing IDs on existing records (which is indeed scary). It is about changing the "next serial ID", i.e. the ID that will be auto-assigned to the next record (yet to be created).

You are right on this. The client wants to change the next value of new records. I warned him of the danger of this but he seems to understand. I believe he wants to be able to change the next serial number when implementing this version of the database at different locations. The idea being that some locations are at a different ID number. These different databases at the different locations do not and will not interact. they are for different clients of his. It isn't something that will be accessible by the average user. I am also going to be creating an import script that should handle that issue but he wanted it just in case.

----

Okay, here is the weirdest part. I just made a clone to upload to this forum. In the clone file the calc works. That is when I open the clone right off the hard drive, not the server(I didn't bother uploading the clone to the server). I checked the backup of the file from the same schedule that made the clone and it still does NOT work...

Thanks for looking at this everyone

Here is the clone file. Login is Admin, no pw

http://dl.dropbox.com/u/2485314/Klinik%20Gut%203.0%20Clone.fp7.zip

P.S.

It's in german but the calc fields are in the Parameter layout. The database is a bit of a mess. The client set up most of it then got in over his head and brought me in

Okay, I figured out what was causing the problem. The file is named "Klinik Gut 3.0.fp7". Apparently something about having the name end in 3.0 was causing the problem. The clone which was name "Klinik Gut 3.0 clone.fp7" worked fine. When I took the "clone" out of the name it stopped working. I then took out the .0 and it worked again. Something about the period causes a problem, but only if it is in the last work. FM Server bypasses this problem. I guess it isn't that surprising considering having any periods in a filename other than that before the extension was a big no no before a few years ago. I just thought Mac had gotten around that. I guess Filemaker didn't. Go figure....

Rings a bell:

http://fmforums.com/forum/showtopic.php?tid/196076/post/294072/#294072