By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
424,652 Members | 1,460 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 424,652 IT Pros & Developers. It's quick & easy.

Sequential numbers without a database?

P: n/a
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
Share this Question
Share on Google+
2 Replies


P: n/a
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

P: n/a
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.