Search options (Page 1 of 109)

Hi Identity,
I think the easiest option (no script) is to go with Jean's suggestion.
1.  use a combobox to select which type of teacher and school (Elementary or High School)
2.  use parent comboboxes to restrict which teachers and which schools are shown.
Derek.

Hi,
All you need to do is add filters to the 'teachers' combobox on Form2 (please have a look at the attachment).
Be aware that the filter values are case sensitive (ie 'High School teacher' will work  but 'high school teacher' will not).
Regards,
Derek.

Salut Identity, Jean,
Ça va les Deux?
Another option is to use 'user authorisations'.
Have a look at the attachment.
The passwords are 'admin', 'Identity' and 'Derek'
Derek can only see 'Elementary Schools'
Identity can see 'Nursery Schools' and 'High School'
Neither Derek nor Identity can see the button to access users (this is only visible and available to Admin).
Derek and Identity get a warning message and cannot access the 'set up' option which shows as disabled.
There are many combinations you can use so it is very flexible and your existing project shouldn't need to have any changes.
Apologies that the data makes little sense (I just quickly changed an old project) but I hope it shows you another possibility.
As a side issue, 20 tables seems quite high;  maybe your data schema could be rationalised (although without seeing your project, it's hard to be certain).
Regards,
Derek.

Hi Igor,
Thanks for your example project - it helps to understand what you are trying to do.
Since you explained that, for your requirement, you always make one order which then becomes one invoice (a strict 'one for one'), I wonder if you even need to have separate tables for orders and invoices - I think it can be simplified much more.
In the attached example, I suggest the following.
1.  You have a table for 'transactions' (don't think in terms of an 'orders' table or an 'invoices' table at all).
2.  The 'transaction' is given an automatically generated reference (record_count)
3.  Each 'transaction' simply moves from one stage to another - it starts off as an 'order', it then moves to a 'delivery', it then moves to an 'invoice' and finally it moves to a 'payment'.
4.  You indicate that the 'transaction' has moved from one stage to the next stage simply by ticking the relevant datetimepicker (order date, delivery date etc etc).  It's very quick and involves no additional input.
5.  As it moves from one stage to the next, a reference is automatically generated (based on the 'transaction reference') to indicate the stage that it has reached (for example O-00012 for an Order, D-00012 for a delivery, I-00012 for an invoice etc).
6.  Additionally a 'status' flag is added ('Ordered', 'Delivered' etc) and this 'status' flag can be used in searches.
I appreciate that your requirement has many more features that you want to add later on but I wonder if this could be the basis from which you can start and build upon.
Apologies for using my own application template (it just means I can create something very easily and quickly) but if the approach in the attachment is useful, you can just copy over the ideas / code etc)
Regards,
Derek.

Hi,
I'm not sure I understand 100% what you need but hopefully the suggestion in the attachment helps.
I have added a new form ('FormDerek') just as a demonstration.
1.  Double click on the 'Name' column will take you to 'FrmEditClients'
2.  Double click on the 'TK Policy' column will take you to 'Yest'
3.  Double click on the 'Endorsment ID' column will take you to 'FrmEndorsment'
(nb.  these columns are shown with an '*' against the column heading in the tablegrid to make it easy for your users to see which columns are interactive).
The code is Lines 8-16 in the script.
Just delete 'FormDerek' when you are finished with it.
I did not know the password so I've removed 'user authorisation'  but you can simply add this again.
Regards,
Derek.

Hi
Can you attach an example of your project.
Derek.

Hi Igor,
Have a look at the attachment which, I believe, does the basics of what you need your application to do.  As mentioned earlier, if this is working, then you can add extra features later on.
The example allows
1.  clients can have multiple orders
2.  clients can have multiple invoices
3.  orders / invoices can have multiple order / invoice lines
4.  orders / invoices can initially be created with no lines if that is a requirement
5.  order lines can be partially invoiced
6.  order lines from different orders can appear on the same invoice
If your requirement was only for one order line = one invoice line, the data schema would be more straightforward but I don't know if that's the case.
Regards,
Derek.

Hi Fmr, Hi Sparrow,
Your relationship is the wrong way round;  the relationship needs to be created on the ''footer'' table pointing back to the ''header'' table.
With very few exceptions, the relationship is always held on the table that contains one or more records that ''belong' to a single record in the other table
A simple example would be a database with two tables - ''customer'' and ''invoice''.   A customer can have many invoices but an invoice can only ever belong to a single customer (so the relationship is created on the ''invoice'' table linking it back to the ''customer'' table.
And so in your example, a ''header'' record can have many items in the ''footer'' table so the relationship is created in the 'footer'' table to link back to the ''header'' table.
Derek.

Hi Jeff,
A couple of approaches you could take but I've kept it pretty simple in the attached example (so rather than using a checkbox and looping through a tablegrid, it works one row at a time as soon as the row is clicked (there's less script and actually slightly less 'clicks' doing it this way too!)).
But irrespective of how you work it, your old data structure was incorrect - you can't simply add records from the 'items' table to the 'clients' table because you don't know how many items the client is going to be associated with (1, 3, 100 etc?) so where are you going to store them?  That's one of the main reasons for using a relational database.
In your case, you need to create a new table ('clientitems' in the attachment) that holds relationships to both the 'clients' table and the 'items' table.  The 'clientitems' table is maintained via the script (look for the 'sqlexecute insert' and 'sqlexecute delete' lines - the rest of the script is just a bit of duplicate record checking and cosmetic stuff to make it a bit more user friendly).
Shout if anything's not clear.
Regards,
Derek.

Hi,
A couple of options to have a go at (see the attachment for a couple).
The first example uses a checkbox to filter the data (just check random rows of data and then click the 'filter by checkbox').  When you're finished working on the list of filtered rows, just click the 'filter by checkbox' again.
The second example takes a different approach (and doesn't actually use a checkbox but uses arrow indicators as being a bit more intuitive for the end-user).
There are other options as well - probably a case of picking the one that best suits your project and/or your users.
Derek.

Hi Adam,
If you use Form2 with borderstyle = none and position Form2 appropriately over Form1, I'm not sure where there is much complexity.  I appreciate that it's not strictly using Form1 for adding/editing nodes on the tree but the end result is, as far as I can tell, the same.
Attached is an amendment to the earlier example with everything but the basic functionality stripped out.
Derek.

Hi
I am unable to replicate your error.
You need to attach the latest version of your project and explain the exact actions you take up to the point that you get the error.
Also, was it working before and you changed something or has it always given this error.
The more information you can give, the better any help that you receive will be - otherwise it's not much more that guessing.
Derek.