Should have been
jerry
-Original Message-
From: ProFox [mailto:profox-boun...@leafe.com] On Behalf Of jerry foote
Sent: Saturday, February 02, 2013 5:05 PM
To: 'ProFox Email List'
Subject: RE: implement auto increment
IN This example I have scattered the contents of my table
ginal Message-
From: ProFox [mailto:profox-boun...@leafe.com] On Behalf Of Gary Jeurink
Sent: Saturday, February 02, 2013 1:13 PM
To: 'ProFox Email List'
Subject: implement auto increment
When I upgraded from vfp-6 to vfpr-9 I was looking forward to the auto
increment to generate the prim
You need to leave the autoinc field out of your insert/update
statements.
___
Post Messages to: ProFox@leafe.com
Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/profox
OT-free version of this list: http://mail.leafe.com/mailman/listinfo/
When I upgraded from vfp-6 to vfpr-9 I was looking forward to the auto
increment to generate the primary keys for many of my tables. I tried
changing the data type from integer to auto increment (no problem) but on my
forms my current INSERT INTO statement generates a duplicate primary key
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 concentra
l!
Dave
-Original Message-
From: profox-boun...@leafe.com [mailto:profox-boun...@leafe.com] On Behalf Of
Gérard Lochon
Sent: 05 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&#x
> 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
espec
o: ProFox Email List
Subject: 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 th
>
> 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 wo
it okay to stay 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 Fr
ating non-unique values when run in the same
timeframe. This was the reason for concatenating the machine name plus maybe the
process id.
Auto-increment was easy and worked well, until my client wanted to bring a
laptop
offline and do real work with it. It turned out that the method I'd started
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 gene
possible though. :)
>With auto-incrementing integer keys, how would you handle offline inserts
>without
>things getting incredibly complex?
I understand the advantages of using GUIDs when you need to able to synch
offline data.
I don't synch offline data in my apps. I'm not
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
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(20
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 <> pr
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" wrote:
I would be extremely surprised if tableupdate() didn't do a behind the
scenes l
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 wrote:
> This is the process:
>
> Seek the reco
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
On Fri, Aug 24, 2012 at 4:18 AM, Paul Hill 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 bytes,
>
> Given 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):
>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 con
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
> >> 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 uniquen
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 go
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 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 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 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
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:4
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
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) fa
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
to write an SQL 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 incre
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 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 val
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)
st 23, 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 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
>&g
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
Same here. And I use with Views, my Views are not stored in the DB.
E.
>
> From: Alan Bourke
>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
rsday, 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 t
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 (at)
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" wrote:
> On 8/23/12 1:09 PM, Lew Schwartz wrote:
> > Unless speed is of the utmost importance, I've used
> >
> >
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 si
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 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 into c
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
_
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 a
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 intege
On 8/23/12 10:47 AM, M Jarvis wrote:
>> On Thu, Aug 23, 2012 at 10:42 AM, 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(2
Stephen Russell wrote on 2012-08-23:
> On Thu, Aug 23, 2012 at 12:35 PM, MB Software Solutions General
> Account 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
>>> wit
On Thu, Aug 23, 2012 at 12:35 PM, MB Software Solutions General
Account 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 have an idea.
>
>
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 vie
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 of
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 vie
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 hard way in a football data base when I
54 matches
Mail list logo
