Offering the user the option of database browsing 1

[AndrewMozley]

An application offers a user with ‘Administrative rights’ the ability to browse any of the tables in the application.
The application lets the user enter the commands in an editbox. So, for example, the user could enter these commands :

[indent]SET DELETED OFF
USE XSDET (A table of sales order detail lines)
BROW[/indent]

The application then compiles and executes these commands, and (in this case) the standard BROWSE window is displayed, showing all the records down the screen and the columns for each of the fields across the screen, (In this case the application usually appends a NOCAPTION clause to the BROW command)

Fields which are numeric are shown in STR(9,2) format. It would be nice to offer an option whereby fields with more decimal places could be shown with their full precision. And fields of type ‘Currency’ could perhaps be shown with 4 decimal places. Could anyone suggest a way that I could offer this facility?

The standard BROWSE command lets the user modify the contents of a table at run-time. It would be nice to continue to offer the user that option as well.

Grateful for suggestions - Andrew

 

[mjcmkrsr]

Hi Andrew,

If it's just a question of display you may want to use BROWSE FIELDS ..... with the P parameter for numeric fields, e.g.

BROWSE FIELDS N_Price :P="999,999.9999"

hth

MarK

 

[Chriss Miller]

I extended my first example of the SET DECIMALS effect:

Create Cursor crsTestData (iNum Integer, fNum1 Float(20,18), dNum2 Double, nNum Numeric(20,18), yCurrency Y,nMedium Numeric(8,4))
Insert into crsTestData Values (1,0.123456789012345678,0.123456789012345678,0.123456789012345678, 0.1234, 100.1234)
Insert into crsTestData Values (2,0.2,0.2,0.1,0.2,0.2)

Set Decimals To 18
Browse

It's working as good as I can imagine.


1. Integers are shown without decimals, That's good.
2. The now added field nMedium with medium precision (subjective, at least it's only 4 decimal places) displays with 4 decimal places. That's good.
3. Currency fields are shown with 4 decimals precision, as Mike also commented already. That's good.
4. The fnum1, dnum2 and nnum fields are all variants used to demonstrate that whatever exact data type you choose, a literal number in code is always victim of conversion precision to double, and double does not allow 18 decimals precision, only 15-16. So you don't see 0.123456789012345678 but only 0.123456789012346 rounded to that possible precision and some trailing zeros. It's not an effect of SET DECIMALS that the data is not what is written into the INSERT SQL code. The precision is as expected, though, and that's also good.

I wonder what does not work for you or your admin user with that help. But I don't think you can get better without needing much more effort. As I saw MarK pointing out BROWSE FIELD also offers specifying formatting. Well, have fun doing this for all fields of a table so you get data displayed with individual formats. It won't cure the precision problems of floats, though.

 

[ggreen61]

I also wrote a program for browsing tables. My implementation is meant to be run as a stand alone app from within the VFP Design-Time environment. However, it should be able to be executed from a VFP .exe program without any problems. Here is the link to the program's compiled app and source code:

GitHub - ggreen86/VFP-Editors: VFP Editors for SCX, VCX. MNU, PRG, and DBF files; also Table Browser and Project Manager Replacements

VFP Editors for SCX, VCX. MNU, PRG, and DBF files; also Table Browser and Project Manager Replacements - ggreen86/VFP-Editors

github.com

 

[AndrewMozley]

Thank you, GGreen. I will check that out.