469,619 Members | 1,867 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,619 developers. It's quick & easy.

Sequential numbers without a database?

Hi all,

I'd building an app that posts to a web service. One of the things
that is required in the soap header is a sequential number appended to
a ref, i.e. "IGI1001", "IGI1002", etc.

Obviously the first part of the reference ("IGI") stays the same, but
I need an incrementing number generated. Now, I was thinking of doing
this via a SQL database, but it would be an awful waste as there would
only be one table and one stored procedure in it. Then I was thinking
of putting it in an application variable: it would be read from a file
at the application start, incremented through the life of the
application, then written back to the file at application end. I
quickly discounted that in case the new number didn't get written back
to the file for whatever reason.

Incidentally, the web service expects the caller to provide the
incrementing alpha-numeric reference, so it won't be done at the web
service.

Any thoughts?

Kind regards,

Mike Kingscott
Nov 18 '05 #1
2 1567
Hallo Mike
"Mike Kingscott" <mi**@kingscott.f9.co.uk> schrieb im Newsbeitrag
news:7d**************************@posting.google.c om...
Hi all,

I'd building an app that posts to a web service. One of the things
that is required in the soap header is a sequential number appended to
a ref, i.e. "IGI1001", "IGI1002", etc.

Obviously the first part of the reference ("IGI") stays the same, but
I need an incrementing number generated. Now, I was thinking of doing
this via a SQL database, but it would be an awful waste as there would
only be one table and one stored procedure in it. Then I was thinking
of putting it in an application variable: it would be read from a file
at the application start, incremented through the life of the
application, then written back to the file at application end. I
quickly discounted that in case the new number didn't get written back
to the file for whatever reason.

Incidentally, the web service expects the caller to provide the
incrementing alpha-numeric reference, so it won't be done at the web
service.

Any thoughts?

Kind regards,

Mike Kingscott


I think, wether it is a waste, to use a sql database. its the safest way to
ensure there is always an incremented number.

regards benni
Nov 18 '05 #2
Any chance you could use a timestamp, or a GUID in the headers to make
them unique? Or does it absolutely have to be a sequential number?

Perhaps you could use a combination of incremented number and a
TimeStamp. The TimeStamp could be the time at which the application
started, say with DateTime.Now.Ticks. The sequential ID could then be
a static field that you increment with the Interlocked.Increment
method.

Possible?

--
Scott
http://www.OdeToCode.com
On 1 Jul 2004 03:25:58 -0700, mi**@kingscott.f9.co.uk (Mike Kingscott)
wrote:
Hi all,

I'd building an app that posts to a web service. One of the things
that is required in the soap header is a sequential number appended to
a ref, i.e. "IGI1001", "IGI1002", etc.

Obviously the first part of the reference ("IGI") stays the same, but
I need an incrementing number generated. Now, I was thinking of doing
this via a SQL database, but it would be an awful waste as there would
only be one table and one stored procedure in it. Then I was thinking
of putting it in an application variable: it would be read from a file
at the application start, incremented through the life of the
application, then written back to the file at application end. I
quickly discounted that in case the new number didn't get written back
to the file for whatever reason.

Incidentally, the web service expects the caller to provide the
incrementing alpha-numeric reference, so it won't be done at the web
service.

Any thoughts?

Kind regards,

Mike Kingscott


Nov 18 '05 #3

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

2 posts views Thread by Ken | last post: by
2 posts views Thread by Tony Williams | last post: by
5 posts views Thread by Lapchien | last post: by
7 posts views Thread by GAVO. | last post: by
reply views Thread by devrayhaan | last post: by
reply views Thread by gheharukoh7 | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.