Search options (Page 22 of 25)

Adam,
Is it a requirement to have refunds in separate tables? A solution could be to incorporate your refund fields in the invoice and invoice items tables. You could still have a tablegrid of invoices filtered on refunds on a separate form, like you have, in order to show just your refunds. Just a thought.

You could do it in separate tables, but thinking off the top of my head I believe it could get a little involved. You would need to connect the refund tables to invoices by setting up relationships between them and then prepopulate the refund tables through script with invoice data upon a refund. And if the user cancels the refund, then you would need to delete the refund records. Also, for partial refunds, if a specific line item does not get refunded, it probably should be removed from the refund item table. As you can see, it can be a bit involved. Nothing is impossible though.

Attached is a possible solution. Not sure if it will fit your scenario, but it's one way to accomplish what you are looking for.

I was about to reply to try to clarify things when I noticed Derek already did. I couldn't have said it any better. Thank you Derek. If I may add more info for Knobby. This may not be evident in the beginning for folks first learning MVD, but whenever you create a table in MVD, an auto increment unique primary key called "Id" is defined for you automatically in each table behind the scenes. If you have a parent-child relationship (linking 2 tables in your terminology), all you have to do in the child table (Calls in your case) is to define a relationship field and select the parent table (Clients in your case). MVD, as Derek mentioned, will define the relationship automatically for you. This is the Foreign Key. The field name is defined automatically for you as "id_parenttable" ("id_Clients" in your case).

If you go into the Database tab in either my project or Derek's project and click on the Database Schema button next to the New Table button, you will be presented with the Database schema which will show the primary keys "Id" in each table and the relationship between the Clients table and the Calls table. It really is an easy process in MVD and much simpler than with Alpha where you have to define and create "Sets" to do the same thing. As I mentioned before I am familiar with Alpha and even though you can set the relationships on other user fields, I never did or do. I always created the parent-child relationship sets using ID key fields, much like MVD does automatically. It's just good database design to do so.

Just to reiterate what Derek said, the only purpose for the script in my project was to populate the Calls table from the CSV file. Again, you do not need to manipulate your CSV file to import into MVD. Derek's example is a good one to show the relationships (linking of tables) without the confusion of the import script which obviously threw you off a bit. I apologize for that confusion and I surely hope I haven't confused you more.

Knobby,
I am familiar with Alpha 5. I have used it as well and still do on occasion. You are right that you can set relationships on any field in Alpha. However, I always used auto increment integers for primary keys, much like MVD does. It's really a better database design to do so. Having said this I used Mathias project and adjusted it to include the CSV import so you can see how it all works using MVD's relationship definition. There is nothing fancy with the code. The only error checking I did was to check to see if there is no matching account number in the CLIENTS table. Errors are imported into an Error table so you can see which calls were not imported. Hope this helps.

Lee, In Dimitry's defense, MVD is a RAD tool to quickly put together a basic application without doing any coding. You really can do that. I have done it myself. However, from my memory of your project, you are trying to develop a rather complex application with a unique design for your first project. There is no tool out there that can create an application design of this nature without some sort of coding or scripting. If you had to develop an application from scratch using the C programming language, you would  be coming back to MVD in a heartbeat. Having said all this, if a person has some experience in application and SQL database design and with some skills in programming, you can create some rather complex applications with MVD. I knew nothing about Pascal when I started with MVD a year ago, but I have experience in other programming languages which helped in learning it. Since you feel you do not want to learn another development language, I suggest that you reach out to this forum to see if anybody would develop the project you want. You may have to pay for it, but you'll get what you want. Somebody with MVD experience could possibly develop it in a rather short time frame. Maybe Derek could help you put it together, if he has time, since he is somewhat familiar with your project already.

Don't be upset with Dimitry. What he says on the website is not false advertising.

Adam, I think you need to be more specific as to what you want to be done with the recurring and reminder alarms. How is the alarm to function and where in the project is it to take place. Define the criteria in showing alarm notifications and inserting recurring alarms.

Hopefully I am understanding your question. You cannot import an Excel file directly. However you can save your Excel file as "CSV" format and import into MVD. If you are only importing one time, you may consider using something like Sqllite Studio to do the import. If it will be an ongoing import, then you can use the script from the following post example to do your import within your project. 

[http://myvisualdatabase.com/forum/viewt … 806#p14806]

You forgot to put in "UpdateDatabase('category');"  in your form1_button3_onafterclick.

Attached is how I would do it.

I added the multi-select to Dimitry's solution.

Forgiveness is not necessary. It's understandable. You're designing and developing simultaneously while learning MVD. That can be challenging. I did change the approach of instant calc based on your request for calculating on entry into the Ending Balance (Edit2). As I said before I do not particularly like that approach because it can be problematic down the road depending on how you use the process in your larger project. It can be dangerous to only fire off a calculation on only one of multiple fields involved in a calculation. If a user changes data in a non-firing field, then no calculation will be performed. Anyway, enough of that. I think you get the picture. The attached is a hybrid of what I had before (and Derek too). It goes back to instant calc with a validity check on the starting balance. Very simple. MVD is pretty flexible in that you can create multiple approaches to tackle various situations.

I am curious though in what the logic is in your Starting Balance and Ending Balance calculation. Unless mathematics has changed since I've been in school, in order to get the difference between a starting balance and ending balance you must subtract the starting from the ending. In your examples 1, 2, 5, and 6 you in fact do subtract the starting from the ending. However, for 3 and 4 you add the two. Does the starting balance take on a new definition when it is negative versus positive. To me a starting balance is a starting balance regardless if it is negative or positive. Just curious.