My preferred method is a UDF() that interrogates a table holding one
record for each table in the system and it's next primary key. Access the
relevant record, lock it for a short period of time whilst incrementing
the next sequential record then unlock and return back the PK. This works
: Re: auto increment
My preferred method is a UDF() that interrogates a table holding one
record for each table in the system and it's next primary key. Access
the relevant record, lock it for a short period of time whilst
incrementing the next sequential record then unlock and return back
Gerard,
That is true for ALL the data not just the pointer table so that isn't an
issue when DBF's are used because the whole of the DBF structure is
available to change as long as the user has access rights.
Yes indeed, that's the genetic lack of open systems, but i wanted to
September 2012 12:06
To: ProFox Email List
Subject: Re: auto increment
Gerard,
That is true for ALL the data not just the pointer table so that isn't
an issue when DBF's are used because the whole of the DBF structure
is available to change as long as the user has access rights.
Yes indeed
On Sep 5, 2012, at 7:51 AM, Dave Crozier wrote:
Embrace new technology and thinking as it is formalised and introduced but
never forget that innovation and logical thinking is normally the way to
solve most difficult programming problems and that is mostly a natural
ability to concentrate
simple with user-id if the
security is really at the gate with user-name password to get in?
Gary Jeurink
-Original Message-
From: Alan Bourke [mailto:alanpbou...@fastmail.fm]
Sent: Friday, August 24, 2012 9:31 AM
To: profox@leafe.com
Subject: Re: auto increment
On Fri, Aug 24, 2012
On 8/24/12 7:18 PM, Ken Dibble wrote:
There are no guarantees in life. But the danger of sys(2015) lies in it's
generation
based on the timestamp. What are the chances of collision on this even not
concatenating the machine name?
Somewhat high, I believe. System clock ticks processor
Hi, Paul
Took about 3 seconds, no duplicates.
Win 7-64, 4 GB memory, 3-core AMD with Folding@Home running in the
background(!).
Dan Covill
San Diego
On 08/27/12 12:21, Paul McNett wrote:
{{{
create cursor temp (gid c(16))
for n = 1 to 100
insert into temp (gid) values (sys(2015))
As always, it depends on what you're doing, how many users, how fast a
network, how many transactions per minute, but:
1) FLOCKing a table means no one can update ANY record, where
2) RLOCKing the one record in the keys table that has the primay key
you're incrementing
has a much smaller window
At 03:21 PM 8/27/2012, you wrote:
On 8/24/12 7:18 PM, Ken Dibble wrote:
There are no guarantees in life. But the danger of sys(2015) lies in
it's
generation
based on the timestamp. What are the chances of collision on this
even not
concatenating the machine name?
Somewhat high, I
The VFP9 help for sys(2015) says:
Calling SYS(2015) more than once during the same millisecond
interval returns a unique character string.
Meaning that the result will still be unique even though you call it
more than once in the same millisecond. I ran Paul's code in 3 seconds,
which
On 8/27/12 7:43 PM, Dan Covill wrote:
Personally, I'd rather use autoincrement, but I still don't see any
evidence that sys(2015) generates duplicates.
I think if I recall correctly the danger was with 2 separate processes of VFP
on the
same or different computers generating non-unique values
Morning Lew,
I agree that vfp will probably do some kind of locking behind the scene.
However, my point was about limiting the time of locking when generating
the next id.
On 25 Aug 2012 18:38, Lew Schwartz lew1...@gmail.com wrote:
I would be extremely surprised if tableupdate() didn't do a
Don't even get me started on 32-bit vs 64-bit operating systems.
Windows 98 could address every spot on a 128 GB hard drive, so why can't
Windows XP address more than 4 GB of RAM? And even if there is some
technical reason for this (as opposed to deliberate planned
obsolescence):
The
On Fri, Aug 24, 2012 at 4:18 AM, Paul Hill paulroberth...@gmail.com wrote:
Hi All,
Guids are nice but can add a significant size overhead to your database.
In my SQL database here I have 86 tables each with a primary key and
547 foreign keys.
Currently I'm using 4 byte ints. Guids are 16
Not sure if I agree with you, Frank. You are still going to have contention
using the separate table method. It'll just be in a different place. Also,
max()+1 will be highly optiimized because it'll be supported by an integer
index on the pk. You've got to lock/unlock and update 2 separate tables
I would be extremely surprised if tableupdate() didn't do a behind the
scenes lock/unlock cycle. Have a look at MSDN Buffering Data:
http://msdn.microsoft.com/en-us/library/aa975707%28v=vs.71%29.aspx
On Sat, Aug 25, 2012 at 6:31 PM, Frank Cazabon frank.caza...@gmail.comwrote:
This is the
Hi Lew,
SELECT MAX() + 1
can result in two or more people getting the same next ID.
If you were running the system at the same time I was, we could both run
that code at almost the same time and end up with the same ID which
could cause no end of problems.
The standard ways to do this is to
On Fri, Aug 24, 2012, at 02:44 PM, Lew Schwartz wrote:
I never understood why these routines would be any better than max()+1.
Because they are GUIDs - globally unique. That fact is very important in
some applications, but overkill for a lot of others.
--
Alan Bourke
alanpbourke (at)
Wow, way over my head, but I've got it and can use it as a stored procedure
and play with it, right? Thanks
Gary
-Original Message-
From: Dave Crozier [mailto:da...@flexipol.co.uk]
Sent: Friday, August 24, 2012 3:52 AM
To: ProFox Email List
Subject: RE: auto increment
Why not use thee
with user-id if
the security is really at the gate with user-name password to get in?
Gary Jeurink
-Original Message-
From: Alan Bourke [mailto:alanpbou...@fastmail.fm]
Sent: Friday, August 24, 2012 9:31 AM
To: profox@leafe.com
Subject: Re: auto increment
On Fri, Aug 24, 2012, at 02:44 PM
On Aug 24, 2012, at 9:31 AM, Alan Bourke wrote:
Because they are GUIDs - globally unique. That fact is very important in
some applications, but overkill for a lot of others.
When OpenStack was first created, it used auto-incremented keys to
identify resources such as servers, volumes,
On 8/24/12 2:18 AM, Paul Hill wrote:
Guids are nice but can add a significant size overhead to your database.
Yes, that is the one disadvantage I've identified, but storage is cheap. It
isn't as
if query performance necessarily goes down as the database grows in size.
Paul
On 8/24/12 10:17 AM, Ed Leafe wrote:
The worst part is that several of us argued for UUIDs from the start,
but lost that discussion to those who favored the simplicity of letting the
database handle key generation.
In my mind, keeping it simple means UUID.
Paul
On Aug 24, 2012, at 3:24 PM, Paul McNett wrote:
Guids are nice but can add a significant size overhead to your database.
Yes, that is the one disadvantage I've identified, but storage is cheap. It
isn't as
if query performance necessarily goes down as the database grows in size.
On 8/24/12 1:29 PM, Ed Leafe wrote:
On Aug 24, 2012, at 3:24 PM, Paul McNett wrote:
Guids are nice but can add a significant size overhead to your database.
Yes, that is the one disadvantage I've identified, but storage is cheap. It
isn't as
if query performance necessarily goes down as
Over the years of my experience with Fox and VFP, I used all kinds of
ways to
generate primary keys, and in retrospect the best ever was
concatenating the machine
name with the output of sys(2015).
Wasn't it true at one time that SYS(2015) didn't guarantee uniqueness?
More like
On 8/24/12 5:21 PM, Ken Dibble wrote:
That's why I concatenate with the machine name. I guess if you are really
paranoid
that a second instance of VFP could be running sys(2015) for the same
table in the
exact same timeslice as the first process you could also concatenate the
process id.
On 8/24/12 5:21 PM, Ken Dibble wrote:
That's why I concatenate with the machine name. I guess if you are
really
paranoid
that a second instance of VFP could be running sys(2015) for the same
table in the
exact same timeslice as the first process you could also concatenate the
Create a little test database with a couple of test views and
experiment!
--
Alan Bourke
alanpbourke (at) fastmail (dot) fm
___
Post Messages to: ProFox@leafe.com
Subscription Maintenance: http://leafe.com/mailman/listinfo/profox
OT-free version
On 8/22/12 12:07 PM, Gary Jeurink wrote:
Now that I've upped from fp-6 to fp-9, I want to change a few tables that
use an integer idno as a primary key to an auto increment type. The only
reason these tables need a primary key is so I can update their values
through a view. I learned that the
On Thu, Aug 23, 2012 at 12:35 PM, MB Software Solutions General
Account mbsoftwaresoluti...@mbsoftwaresolutions.com wrote:
On Wed, August 22, 2012 6:14 pm, Tracy Pearson wrote:
I believe changing a column to auto-increment is not a breaking change
with the views. I may be wrong, perhaps others
Stephen Russell wrote on 2012-08-23:
On Thu, Aug 23, 2012 at 12:35 PM, MB Software Solutions General
Account mbsoftwaresoluti...@mbsoftwaresolutions.com wrote:
On Wed, August 22, 2012 6:14 pm, Tracy Pearson wrote:
I believe changing a column to auto-increment is not a breaking change
with
On 8/23/12 10:47 AM, M Jarvis wrote:
On Thu, Aug 23, 2012 at 10:42 AM, Paul McNett p...@ulmcnett.com wrote:
Over the years of my experience with Fox and VFP, I used all kinds of ways to
generate primary keys, and in retrospect the best ever was concatenating the
machine
name with the output
On Thu, August 23, 2012 1:42 pm, Paul McNett wrote:
Over the years of my experience with Fox and VFP, I used all kinds of
ways to generate primary keys, and in retrospect the best ever was
concatenating the machine name with the output of sys(2015).
In my opinion, auto-incrementing integer
On 8/23/12 11:48 AM, MB Software Solutions General Account wrote:
I use 40-char GUID's in my Python work, but to get those in VFP you'd
have to rely on an external library which could slow you down compared to
VFP's sys(2015).
Neat tip. So how wide is your PK field using this approach?
On Aug 23, 2012, at 3:09 PM, Lew Schwartz wrote:
Unless speed is of the utmost importance, I've used
select max(idno)+1 as idno from target into cursor nextkey
to get the next value.
Are all your systems limited to a single user?
-- Ed Leafe
Hmmm. Hadn't thought of that. I guess it'd still work with the right locks
in place.
On Thu, Aug 23, 2012 at 4:11 PM, Ed Leafe e...@leafe.com wrote:
On Aug 23, 2012, at 3:09 PM, Lew Schwartz wrote:
Unless speed is of the utmost importance, I've used
select max(idno)+1 as idno from target
On 8/23/12 1:09 PM, Lew Schwartz wrote:
Unless speed is of the utmost importance, I've used
select max(idno)+1 as idno from target into cursor nextkey
to get the next value.
Sorry, but I disagree. You'd have to do this inside a locking mechanism, unless
you
are only talking about a single
I like random, unique strings too. Incrementing integers give a
chronological footprint which is sometimes interesting or useful.
-Lew Schwartz
On Aug 23, 2012 4:25 PM, Paul McNett p...@ulmcnett.com wrote:
On 8/23/12 1:09 PM, Lew Schwartz wrote:
Unless speed is of the utmost importance, I've
We use a next id free table which stores a next id value for a range of
table names. New records in these tables trigger a stored procedure
which retrieves the next id value. This works pretty flawlessly on
hundreds of sites, some with 40 or 50 concurrent users.
--
Alan Bourke
alanpbourke
, August 23, 2012 12:36 PM
To: ProFox Email List
Subject: RE: auto increment
On Wed, August 22, 2012 6:14 pm, Tracy Pearson wrote:
I believe changing a column to auto-increment is not a breaking change
with the views. I may be wrong, perhaps others have an idea.
You can't have the AutoIncrement key
Same here. And I use with Views, my Views are not stored in the DB.
E.
From: Alan Bourke alanpbou...@fastmail.fm
To: profox@leafe.com
Sent: Thursday, August 23, 2012 6:26 PM
Subject: Re: auto increment
We use a next id free table which stores a next id
Security is not an issue. Just need a unique number and I figured auto
increment would save writing a whole procedure.
Gary Jeurink
-Original Message-
From: Paul McNett [mailto:p...@ulmcnett.com]
Sent: Thursday, August 23, 2012 12:43 PM
To: profox@leafe.com
Subject: Re: auto increment
, 2012 12:49 PM
To: ProFox Email List
Subject: Re: auto increment
On Thu, Aug 23, 2012 at 12:35 PM, MB Software Solutions General
Account mbsoftwaresoluti...@mbsoftwaresolutions.com wrote:
On Wed, August 22, 2012 6:14 pm, Tracy Pearson wrote:
I believe changing a column to auto-increment
Does max(idno)+1 work if my view is a filter list?
Gary
-Original Message-
From: Lew Schwartz [mailto:lew1...@gmail.com]
Sent: Thursday, August 23, 2012 3:09 PM
To: ProFox Email List
Subject: Re: auto increment
Unless speed is of the utmost importance, I've used
select max(idno)+1
: Thursday, August 23, 2012 3:12 PM
To: ProFox Email List
Subject: Re: auto increment
On Aug 23, 2012, at 3:09 PM, Lew Schwartz wrote:
Unless speed is of the utmost importance, I've used
select max(idno)+1 as idno from target into cursor nextkey
to get the next value.
Are all your
statement
Does max[id]+1 work on a filtered list or does it just look at that list?
Gary
-Original Message-
From: Ed Leafe [mailto:e...@leafe.com]
Sent: Thursday, August 23, 2012 3:12 PM
To: ProFox Email List
Subject: Re: auto increment
On Aug 23, 2012, at 3:09 PM, Lew Schwartz
Gary Jeurink wrote on 2012-08-22:
Now that I've upped from fp-6 to fp-9, I want to change a few tables that
use an integer idno as a primary key to an auto increment type. The only
reason these tables need a primary key is so I can update their values
through a view. I learned that the
49 matches
Mail list logo
