>>What are the Pros and Cons of using GUIDs vs Integers for Primary Keys on a Web based application.
>
>In either case, (unless your backend is SQL Server) you have to generate the value. There are some factors that you should consider. If your backend is a native VFP table, the GUID will have to be stored as character and will take up 32 bytes. OTOH, an integer PK takes up only four.


Here's an excerpt from a great book, "Creating VFP Apps with Visual FoxExpress" by Bob Archer & Dan Jurden:

*----------------------------------------------------------------------------*
A GUID is a 128-bit string generated by the operating system. The number is generated with a combination of the network card's MAC address (a unique number assigned to every Ethernet card made) and the current time. The number is said to be unique across space and time, and no two will be duplicated. The GUID is actually stored in hexedecimal form in a 16-bit binary field.

- With GUID, the concept of "losing" keys doesn't exist. With integer keys, many people have concerns about generating a key value in a field that ends up being discarded.

- The GUID can be generated at the client and the server. There is no need to communicate with another machine to generate a GUID value, which increases performance, especialy in bulk data processing situations.

- No support file is need to maintain the last value used. In addition, because there is no support file to query, there are no multi-user performance or conflict issues.

- If you're dealing with a situation where data entry wil take place offline, or if data from disconnected users will ultimately be combined, GUIDs will maintain their uniqueness.

- In a remote or distributed deployment, there is no network traffic generated, nor is there a back-end hit needed to create a GUID value.