if it does not involve SQL then i may be able to help

Microsoft access is what i use, mainly involving VB code, what ya needing?

... I use Progress (obscure and expensive) for work, but have done a little Access/SQL/VB here and there.

Feel free to PM me if you want a second/third pair of eyes.

Hehe, right.

Well, I have been given the task of generating an internal sales database, that is to catalogue the following.

Customers (address, names, phone nos etc etc)

Product listing (detailing our product, prices, lead times etc)

Internal Sales enquiry (Take initial details of customer enquiry, name, items required, dates, persons dealing with enquiry)

External Quotation (Generated from the details on the enquiry form, but detailing prices, lead times, etc)

I reckon its deffo a relational database.

Initial problem areas/things that are required.
1) Im not too hot on relational databases (well, rusty)
2) Its going to be used on a LAN (shared machines, no hard server) so 4-5 people might view and edit data at the same time.
3) Im torn between access and filemaker, both are good, apparently filemaker is the next gen of database developer software.
4) Although there is a product listing table, that can be used to automatically lookup the part that is being enquired about on the enquiry form, I would still like to be able to write hard text in the field incase its a custom part.
5) When the enquiry is taken, when completing the quotation all the info will be pulled into the form from the enquiry.

I have read 2 white page books on filemaker and access, but am still thinking im going in over my head.
I also have a bible on filemaker, but it seems a little advanced, well not advanced, I think its just me not knowing database fundamentals very well.

Last time I used DBASE4 to develop a database that had related tables.

Definitely a relational DB needed.

I must confess I have to never heard of "filemaker" - it may be good but if in doubt then go with Access.
It's "plug-inable" to many things, has pretty much universal ODBC support ...and at the end of the day we're all Uncle Bill's bitches.
(in English - everyone uses Access, everyone supports Access, everyone can link to Access).

If you can come up with a list of data that is needed then I'd be quite happy to knock up a decent database for you with the tables mentioned.

I must confess to being a bit "in the dark" regarding query/access rights to an Access DB as I don't use it for "real" applications but I guess it must handle things OK.

To come up with the tables/indexes you need to come up with a list of everything you want to keep, and how they relate (e.g. one customer has multiple orders. one customer has a single address, one order applies to one/multiple items, etc).

Usually around on the weekends, so PM me or post if you want me to do some digging for you - I know a bit an can probably find out the rest.

w00tage!

Cheers mate, to be honest Id like to develop the DB myself, for the simple fact that I need to learn, I would however like to use you as a mentor for the project, or as my teacher.

I have heard and read in places that to make it user friendly on a shared network people often develop a "parameters" table. This equates to a simple table that contains unique user details, this is the first table looked at by the database, enabling more than one person to use the database as other fields are global? I dont know what it means TBH.

I have some experience designing relational databases and the best tip I can pass on is:

- Don't use encoded primary keys

To explain, each table in a relational database must have a primary key in order to uniquely identify a record in the table. A common mistake is to make an apparently "unique" data field (or combination of fields) the primary key - eg. Company Name, or combination of Surname + First Name. This will get you into all sorts of problems when your seemingly unqiue/unchanging field changes - for example, Midland Bank became HSBC, Miss Karen Jones becomes Mrs Karen Smith, etc. When you change the primary key, you break all of the foreign key links in the related tables. Access has something called Cascaded Updates to propogate the changes to the primary key - but you'll more than likely have to perform search and replace type operations.

The trick is to use a "meaningless" key as your primary key. I use autoincrementing Long Integers as my primary keys - so it means that you usually have to add an Id column to your top level tables - eg. CustomerId, ProductId, QuoteId, etc.

If this doesn't mean anything to you, don't worry about it too much now - it'll most likely present itself way down the line and shouldn't affect your early design too much.

Check out this online demo of an open source CRM that may give you some ideas about what tables and fields to add to your design:

http://demo.sugarondemand.com/sugarcrm_os

Good luck

Just a thought - consider MSDE instead of Access.

It's a cut down version of SQL server, it's free and you can write proper stored procs in it.

If you want to write the front end separately to the DB, then this is a nice (cheap) solution.