Search options (Page 95 of 104)

Hi Again Adam,
I think I understand the scenario you're trying to trap so I've added a simple test for an invoiceheader record with no associated invoiceitems records and, where this is the case, automatically delete the invoiceheader record to get everything straight again.
Remember that the invoiceheader record is actually saved when you click 'add an item' and not when you click 'save header'.  I can see why it is confusing but it is logical - it is done this way otherwise the invoiceitem record would have no 'parent' at the point when it gets saved.
Derek.

Hi Adam,
Not being technically minded, I probably approach the problem from a different angle to other users. 
I find there are occasions when I want to 'check' what has been entered (or not entered) but it's too late once 'save' has been clicked.  So, I create a 'pre-save' button which just runs any required validation in a script.  If okay, the script then clicks on the 'real save' button.
There are a couple of extra things;
1.  I always set the 'real save' button enabled property to false initially;  this prevents the record being saved if the user accidently presses 'ENTER / RETURN' instead of 'TAB'.
2. I also set the 'real save' button visible and tab-stop properties to false.  Therefore, the button you actually see and click is the 'pre-save' button, not the 'real save' button.
As always, it is much easier just to see it working, so I've added it to your script.
Hope this helps,
Derek.

Hi,
You have called the fields in the 'lookups' table 'key' and 'value'. 
However, in your calculated fields you reference it as 'lookups_value';  it should be 'value'. 
In the combobox  'filter' object property, you reference it as lookups_key;  it should be 'key'. 
Two of your calculated fields have a leading space in their name (not a problem now but maybe later??). 
See the screen capture in the attachment along with the project with the calculated fields and the object properties for the comboboxes changed as per above.
Derek.

Hi Adam,
Attached is your project with an example of how you can do it by script (which is, to my knowledge, the only way);  it allows the user to scroll through the grid using both mouse and keyboard (only having one or the other would be confusing for users).
It is not possible with your current structure to display details from the 'classes' table in the same way because you don't have a relationship (join) between the 'people' and the 'classes' tables.
Regards,
Derek.

Hello Kkalgidim,
I hope I have understood your problem.  I have made 2 changes.
1.  In your tablegrid, change siparis.id_kim to kim.isim
2.  Use a calculated field (siparis.cfisim) to get the description of the delivery person and then in the tablegrid, change siparis.id_kim1 to siparis.cfisim.
Maybe this has fixed it for you?
Derek.

Hi Adam,

Ask 100 people and you'll get 100 different answers!  And while the theory of relational database design MIGHT be a good place to start, there are also practical reasons why you might end up doing things differently.

To give a brief response solely to your diagram, I would make the following comments (just my view, not saying it's right or wrong!)
1. I would remove 'invoice' table and have 'invoice_header' table (with fields for invoice number and invoice date) and 'invoice_line' table (with fields for qty).  Curently, you are repeating the invoice number and invoice date - a 10 line invoice will have the invoice number and the date repeating 10 times
2. Storing Net price is redundant -it is simply the result of the calculation of invoice_line.qty*products.unit_price
3. Obviously, you'll need your joins (customer to invoice_header, invoice_header to invoice_line, invoice_line to products)

But now the fun starts.  Consider these scenarios:
1.  The price of the product changes - you probably don't want the new price reflected in the invoice.  So you might deliberately choose to copy the unit_price from the 'products' table and then hold it on the invoice_line table (introducing data redundancy).
2.  The same goes for tax_rate - that could change as well.
The theorists would probably have you create new tables for product price changes and tax rate changes with 'from' and 'to dates and relate it back to the invoice date.  The pragmatists would probably suggest you initially look-up the 'products' table to get the unit_price and the tax_rate, but then actually hold unit_price and tax_rate on the 'invoice_line' table.
3.  Do you need to know the value of the invoice?  The theorists might have you perform invoice_line.qty * products.unit_price and then sum up the result for all of the lines in the invoice.  The pragmatists might say that it's something you frequently need to know and it takes too long to perform the calculation every time.  So, for the sake of a quick response time for the user, it's okay to deliberately introduce data redundancy and have a field called invoice_header.invoicetotal where the calculation is performed once and then stored. 

These are just a couple of simple issues you need to consider when designing your application. 
Even more important, you might have to consider whether MVD does it easily (with no script) one way, but doing it another way might involve significant complexity and a lot of script writing.   I know the software SHOULDN'T determine the approach you take, but it's a fact of life!

Not sure if any of that helps and, as I said, just my view!

Derek.

Bonsoir JB, Adam, tout le monde!
The reason why I created the 'derekclearform' procedure is to stop a slight error happening.  For example:
1.  You click 'add a new record' but maybe get interrupted, so you press 'cancel' instead of 'save'. 
2.  The next time you 'click add a new record', the 2 'not null' edit fields (in this case, 'name' and 'surname') have not been cleared out. 
Admittedly, 'derekclearform' could have just specified the 2 'not null' fields but for completeness, I added the others as well.
Hope that makes sense.
Derek.

Hi Adam,

What you are looking for is "in grid editing" which is, I believe, something that was introduced in Version 2.0 (and one of the main reasons I upgraded).   New additional grid object properties of 'go input' and 'go inplace editevents' appeared (and many more) but I am not sure how they are meant to work (if, indeed, they do).  It is a pity that tablegrid improvements seem to have been down-graded in recent releases, considering how 'core' to MVD the tablegrid is and how many issues in this forum relate to tablegrid problems.

Ticking 'go input' gives you a row above the grid which can be used to enter new data but doesn't appear to work if you what to edit entries (you still need to use the usual edit text box components and so you've gained nothing).  Further, using 'go input' doesn't give you any validation that you might have set up for your edit text boxes (although I suppose you could script it, but that's not the point).

So, short answer to your question,I believe, is 'no'. 

Derek.

Hi Adam, Jean,
Attached is the way I would do it - there are other ways too but I always go for the easy life - LOL!
Have a look at the script - I think it's pretty self-explanatory but give us a shout if something's not clear.
Derek.

Great.  Glad it helped.
Derek.

Hi Adam,
See attached screen shot.
Derek.