Calculated Control in Text Field 3

[Terpsfan]

I'm building a front end application in Visual Basic 6 using ADO 2.5 to a SQL Server 7.0 back end. I've created the front end form, created the connection to the SQL Server database and bound the text fields to the SQL Server table. Now, I would like to create a calculated control in a few of the text box controls, such as a Date function or a Sum function. Where would I put the function? Do I put it in the Caption or Text property, or elsewhere? Or should I just put the function in a query that the form is based on? If someone could provide an example, I would be very grateful.

 

[culshaja]

If you wish to have a calculated feild then I would put it in the query that retrieves the data from the SQL Server.

James James Culshaw
jculshaw@active-data-solutions.co.uk

http://www.active-data-solutions.co.uk

http://www.brainbench.com/transcript.jsp?pid=193305

 

[MichaelRed]

Omega,

This 'question' has approximatly n^n answers, where N is number of individuals responding. Where you do a calculation is an intergal part of the design. It depends on so many factors that no answer is the 'best' or only. I generally like to follow a few simple rules - but be ready to volate them in any instance where they appear to impede my progress or to hinder the operation of the application.

Rule 1.[tab]Dont't save extra information - especially that which may be re-calculated from data which is saved.

Rule2.[tab]Calculate additional 'values' (either individual fields or recordsets) at the latest point in the program which will make it available when it is used (or displayed). This would generally mean that I would place functions in Form Events before burdening the form's recordsource (a query) with the calculation.

Rule 3.[tab]Don't calculate complex items in a query (e.g. nested IIFs) Break these out into functions and call the function from the query.

Rule4.[tab]Don't allow the User to input information in 'free form'. Where possible give the User choices like chel boxes; option grouops; Como Boxes; .... Calculate valid choices and let the User select from these to the MAXIMUM extent pratical (e.g. If the User needs to select date ranges for the start/end of a report, give him options for month; week; quarter ... when he selects form these options, calcualte the relevant dates - DO NOT allow/encourage the User to type in dates!

Rule 5.{tab]Always track the user actions in modifying the data base or generating recordsets (usually for reports). For the database changes, I generate a 'transaction log' of each field modification - including record addition ans deletion. For the recordsets, I generally build forms/reports to include the form/report name and the User selected options within the report.

Rule 6.[tab]Use error trapping and reporting EXTENSIVELY. In most instances, I log errors to a table in the app and to a text file.

Rule 6.[tab] rember Shakespear
[tab][tab]"I know I'm paranoid. The question is wheather I'm paranoiod enough!"

Rule 99.[tab]There are other rules, hwever these should get you started.



MichaelRed
mred@duvallgroup.com
There is never time to do it right but there is always time to do it over

 

[tedsmith]

I would put the calculation function outside the bound text box in a normal function or sub and feed the result of the calculation into the data bound text box. One example had was to calculate and store a due date by entering a single number equal to the days leading up to that date. Because you can't enter a number in a date field I had to enter the days in another unbound field called DueDays, in the DudDays_click sub, I put DueDate.Text=dateadd("d",EnterDays.Text,Date).
If the entry is the same format expected by the box then you can enter the value in the data bound box and put the calculation in keydown sub activated after the required number of keys have been pressed.