Search options (Page 8 of 25)

Anakin,
See attached for the revised fixed project. Classification and Variant are correctly defined as a relationship to Product, so you really should not have it related to Sales. But in order to bring in those two fields into the Sales tablegrid I created calculated fields to retrieve the respective names. Keep in mind that calculated fields are not real fields so it is not duplicating data in the Sales table.  Also, the controls for these two fields in the NewSale form are defined as ReadOnly.  You cannot change them in this form because they belong to Product, not Sales. Hope this helps.

I just noticed that you asked about placing the Payment and Change in the tablegrid. All you have to do is define them in the Sales table, then put the definitions in the object Inspector of the Sales form. Don't forget to include them in the Save action.

Very good point Derek. I did overlook that aspect. I made an assumption that everybody who comes to this software has a database design background. You're absolutely correct. The proper database design is the main foundation for all database applications. It is essential for a successful project. Thanks for your input.

kees.krause,
If you want to use my solution I updated the project and added address and then checked for a duplicate after making changes to a record. So if the user updates the fields and the result of the changes will produce a duplicate then present the duplicate error message otherwise it will save the changed data. If you do not want to use the address as part of the duplicate check, then remove it from the SQLEXECUTE statements and the Hold_Flds and FLD_Concat variables.

It sounds like you may have inserted another column in front of the product name in the tablegrid. If you did then you need to change the FOR LOOP to point to UNITS column in the tablegrid.

Whatever the column number is for UNITS beginning with Column 0 then replace the digit 1 below in Cells[1,i] and Cell[1,i] with the appropriate number. In other words, if the UNITS column is now the third column in the tablegrid, then you want to replace the 1 with 2.

If StrToInt(Inventory.TableGrid1.Cells[1,i]) < 1 then
           Begin
              Inventory.TableGrid1.Cell[1,i].TextColor := clRed;
              Inventory.TableGrid1.Cell[1,i].FontStyle := fsBold;
           End;

I would recommend doing what I did, especially if one is new to MVD, and that is create a database (in MVD of course) of code snippets and examples. I use it as a kind of help system for MVD. I refer to mine almost daily. When I first came to MVD I was using the forum for most of my assistance, but I found out early on that it can be laborious trying to find what you are looking for, even when using the search tool. Many times there are solutions in topics where the topic title has nothing to do with the solution itself or somebody may post another subject under a topic in question. Don't get me wrong, the forum is an invaluable tool for assistance. I have learned most everything from the forum and it provides the basis for updating my code snippet database. I download most every project attachment and if there is something in the project that is new or something I did not know, then I insert the code snippet in my database for future referencing. That way I don't have to go back to the forum to try and find it a year later or whenever.

denzkie1191,
Attached is another option. As you can see, MVD is very flexible in doing things in various ways. Not one is really any better than the other.

You need to place your IF statement inside the OnChange event of the combobox. See attached revision.

Anakin,
I made some guesses and assumptions in what you are wanting to do. I revised your project and hopefully my changes gets you closer to what you are looking for. I didn't do anything with CLASSIFICATION or VARIANT in your project. I assumed that the table Product represents inventory whereby UNITS would be the same as qty on hand. The calculated field in Product represents the value of the inventory items. If these assumptions are correct then when you make sales, the UNITS (qty on hand) in Product table gets updated based on the sales transaction units. The NewSale form can be used for adding and editing sales. The PAYMENT and CHANGE fields are only used to calculate the change amount back to the customer. I don't think it is necessary to actually store those amounts so I removed them. But you can add them back if you need to. I put code in to retrieve the product price from the PRODUCT table when a product is selected from the combobox in NewSale form. Most of the code in the project is for the maintaining of the UNITS (qty on hand) in Product table. That code is at the bottom of the script. If you don't need it then you can remove it.

I also added code to change the UNITs cell in the Products tablegrid to RED if the UNITS qty is zero or below.

I'm not sure why you have UNITS as a search item in the Inventory form. I left it alone.

CDB,
In the ForeignKey field property, do not select anything from the dropdown. Just type in the table name Supplier, then you can select the Sup_Name from the FieldName dropdown.

EDIT - I am updating my post to support Derek's approach. I was wondering where he got your project and then I saw you had it in another post. After looking at your original project, in my opinion, it would better serve you to use Derek's approach. It is easier, more straightforward and less scripting. It appears you are trying to use tabs rather than forms for various updates and it can become cumbersome with scripting to try to do a lot of things on one form. Not that you can't do it, but it can be complex. In Derek's project, you could almost simulate tabs by placing the buttons above the tablegrid on the first form.  Just a footnote, I typically only use tabs if I have a lot of fields in a record and there are too many to fit on a form. I can spread them in a logical way on separate tabs, but on the same form. Obviously it is not the only use for the tabs, but I just wanted to show you one way for its use.

Hope this helps with your development.

blackpearl8534,
Even if your code would work I hate to say this but it is very inefficient. You are spinning through the tablegrid every time you click on it just to get the info from the selected row. You do not need to do this. As soon as the user clicks on a row it is selected so you can get the cell info from the row immediately. See below.

procedure Form1_TableGrid1_OnCellClick (Sender: TObject; ACol, ARow: Integer);
begin
   Form3.Edit3.Text := Form1.TableGrid1.Cells[2,ARow];
   Form3.Edit4.Text := Form1.TableGrid1.Cells[3,ARow];
   Form3.Edit5.Text := Form1.TableGrid1.Cells[5,ARow];
   Form3.Edit6.Text := Form1.TableGrid1.Cells[6,ARow];
   Form3.ShowModal;   // or whatever you want to do at this point
end;

Let me know if you still get the error.

Dimitry created an example

http://myvisualdatabase.com/forum/viewt … 652#p21652