ProFox May 2020

profox@leafe.com

21 participants
13 discussions

[NF] Recommendations on a balance board for standup desk use
by Malcolm Greene 23 Jun '20

23 Jun '20

Any of you stand-up desk users standing on a balance-board type contraption or using a specific mat? I'm at a standup desk 8-12 hours/day and looking to improve the ergonomics of this situation. Thanks! Malcolm --- StripMime Report -- processed MIME parts --- multipart/alternative text/plain (text body -- kept) text/html ---

5 16

[NF} Thanks For This Group!
by Paul H. Tarver 29 May '20

29 May '20

This morning I was pulling out what little hair I have left trying to make an programmatic ADODB connection to a Pervasive (btrieve) database from VFP with no success. I started to write up the problem to submit it to this group to see if I could get an assist in figuring out my problem and in the process of trying to explain it in an email, I realized what I had done wrong, make a change in my code and voila! Problem solved! Sometimes just knowing there is a group of like-minded individuals I can turn to is enough to solve even the toughest problem. You guys have always been there for me when I needed it, occasionally even before I submit a question like today, and I just wanted stop for a moment and say thank you. Thanks to Ed for keeping this whole thing going. Thanks to everyone who contributes questions and answers. I learn more from your questions and answers than you will ever know. This resource is one of my favorites and I refer back to past emails almost daily. Y'all have made me a better programmer and I appreciate it. Just wanted you to know it. Paul H. Tarver --- StripMime Report -- processed MIME parts --- multipart/alternative text/plain (text body -- kept) text/html ---

4 4

Virtual Fox Fest 2020: Call for Speaker Deadline
by Rick Schummer 29 May '20

29 May '20

Just a reminder that the deadline to submit session proposals for Virtual Fox Fest is next Monday, June 1st. You'll find details on our Call for Speakers page (https://virtualfoxfest.com/CallForSpeakers.aspx) We look forward to your ideas and session proposals. Virtual Fox Fest is October 15, 21, and 27, 2020! Rick White Light Computing, Inc. www.whitelightcomputing.com

1 0

Populating Microsoft Outlook address book using a list of emails from a CSV file
by MB Software Solutions, LLC 28 May '20

28 May '20

Customer wants to pre-seed his Outlook contacts with a CSV list to save him time later when actually emailing these people for the first time. Haven't dove into this yet but wanted to throw it out to the group in case someone has already "been there, done that, here's the plan." tia! --Mike

4 4

Virtual Fox Fest 2020: All new virtual Fox conference in October, Southwest Fox hiatus until 2021
by Rick Schummer 27 May '20

27 May '20

We're disappointed to announce that due to COVID-19, the annual Southwest Fox Conference is on hiatus in 2020. However, we're excited to offer you Virtual Fox Fest, an online conference presenting the latest in Microsoft Visual FoxPro development techniques and interoperability with other technologies. This conference provides a venue for VFP experts to come together virtually to learn more about how our fellow programmers are using and extending VFP. For details about Virtual Fox Fest, please see https://virtualfoxfest.com. We've issued the Call for Speakers (https://virtualfoxfest.com/CallForSpeakers.aspx) for Virtual Fox Fest. If you are interested in presenting, please read the document referenced in that page and consider submitting sessions. If you previously submitted sessions for Southwest Fox 2020, you don't need to resubmit for Virtual Fox Fest (but feel free to delete or revise your prior submissions or submit new sessions). Rick White Light Computing, Inc. www.whitelightcomputing.com

5 7

Memo bloat
by Paul Newton 27 May '20

27 May '20

Hi all I have a table with a memo field. It contains ca. 970 records and the size of the FPT is ca 230KB. I added 161 records to the table, populating the memo field with several lines of text (the total size of all the text added was ca 700KB). In each case the memo field was a single replace (no memo = memo + ..., no replace memo with .... Additive). The FPT ended up as 234MB but a PACK MEMO reduced this to ca 935KB. The trouble is that this is a widely used table in a multi-user environment and it would be impractical to use PACK MEMO on a regular basis. Blocksize is set to 64. Any suggestions or comments would be very welcome. Thanks in advance. Paul Newton

7 10

AW: Memo bloat
by Jürgen Wondzinski 26 May '20

26 May '20

Just to add a little tidbit information for "why is this FPT behaviour done that way": In the early days of dBase / FoxBase, computers only has those 640kB of RAM, from which only about 500 or so have been usable. And in FoxBase we had whopping 64kB as reserved space for variables. Some of us might still remember that time :) With the invention of MultiUser programming we learned to GATHER/SCATTER our tablefields to temporarily keep a copy in memory as well as revert data in case of problems. The same approach is used internally by the dataengine: To be able to revert interactive changes, the engine has to save a copy of the fields. That approach works well with standard C/N/D/L fields, but what to do with Memofields, which even at those dark ages already had a maximum of lunatic 2 GigaWatts, err GigaBytes? You can't just copy 2 GBytes to a MemVar (with 640k Memory!) Thus they decided to approach a different path for editing Memos: Memofields get always edited at disklevel, in contrast to Charfields, which get edited on a MemVar. To get Multiuser working, they always locked the original Memoblock(s), copied the content to the end of the memofile and edited there. If the user reverts the edit, then they just scrap the just appended junk and release the lock on the original memoblock(s), but if the user saves the changes, then the new blocknumber is recorded in the DBF field-pointer, and the old memoblocks are then no more referenced, thus leaving them in the memofile as junk or useless filler. Thus, with every edit a FPT will always grow for the size of the original blocks (plus the blocks to fit additional edits), and it always grows in multiples of the allocated blocksize. At VFP8 betatest times (as far as I remember) they tried to change that behaviour of "always copy to a new block" to only occur if the table is used sharable. In VFP9 this is not the case, a FPT also grows in exclusive mode. The above revert-logic also debunks the "if the edit isn't changing the original length, it will not grow" myth :) . The block size is just a preallocated tablespace for your edit. It also pays to analyze the best blocksize-setting for your data and do a SET BLOCKSIZE TO x before creating a new FPT (you cannot change the blocksize of an existing FPT). There's a gotcha here: Values from 1 to 32 are Multiples of 512 Bytes (which therefor results to blocksizes from 512 Bytes to 16384 Bytes), and from 33 to 32768 they are taken literally. (Default is 64 bytes). A value of 0 results in "no preallocated blocksize", the block grows as needed, but will therefor always get appended. Blocksize 0 is used on all Metadata files (SCX, MPX, VCX, FRX etc) Another gotcha: ? SET("BLOCK") just tells you the setting for newly created MemoTables, you need to use SYS(2012) to get the blocksize of the currrent table. BTW 1: It also is not possible to do some sort of recycling those dead junkspaces in a FPT, since you don't know beforehand how big the needed space would be to store your new data and find a fitting dead space. BTW 2: Blocks are always used in consecutive sequence, there's no way to connect several fragments spread over the FPT. Only the first blocknumber gets stored in the DBF-to-FPT pointerfield. That's why we have the PACK MEMO command, which just copies the referenced block-chains to a new file. -----Ursprüngliche Nachricht----- Von: ProFox <profox-bounces(a)leafe.com> Im Auftrag von Christof Wollenhaupt Gesendet: Dienstag, 26. Mai 2020 16:09 An: ProFox Mailinglist <profox(a)leafe.com> Betreff: Re: [SPAM] Memo bloat Hi Alan, > If the changed data in bytes > blocksize then it will add a new block. If you keep the changes < blocksize then it will re-use the same space. The trouble is with a blocksize of 64, it's very likely that it will almost always be adding blocks. That would be very thoughtful of VFP, indeed, but it's unfortunately not what is happening: Set Blocksize To 64 Create Table memotest (memofield M) Use memotest shared Insert into memotest values ("1234567890") Use Dir like memotest.fpt ? Use memotest shared Replace memofield with "54321" Use Dir like memotest.fpt ? Use memotest shared Replace memofield with "1234567890" Use Dir like memotest.fpt The code replaces the same field with a shorter string, then with a longer string. All strings are way below the blocksize. Yet, each time the FPT file grows by 64 bytes. -- Christof

1 0

Paradox data viewer and exporter?
by Kevin Cully 25 May '20

25 May '20

I just heard from our CIO that there is a old Paradox system that they would like to export some data to Excel. She's not able to connect to the Paradox tables via a vendor supplied ODBC connection. It might be a version issue or perhaps she doesn't have all of the data tables properly downloaded. Has anyone used a Paradox Data Viewer to export the data that they can recommend? Thank you, ahead of time. -Kevin

3 3

[NF] gmail tracker
by Charles Hart Enzer, M.D. 20 May '20

20 May '20

Recommendations for Gmail Tracking? - Who - Who with multiple recipients - When - Frequency Thank you. -- *Shai / שי **Charles Hart Enzer, MD(Retired, **Ohio**), FAACAP* *Aliyah <https://en.wikipedia.org/wiki/Aliyah>: Cincinnati to Jerusalem <http://www.gojerusalem.com/items/263/German-Colony/>'s German Colony <https://en.wikipedia.org/wiki/German_Colony,_Jerusalem> May 2017* *Volunteer Associate Professor of PsychiatryUniversity of Cincinnati Medical CenterWebSite: **EnzerMD.com <http://EnzerMD.com>* *Publications* <http://www.enzermd.com/CV.html#Publications> *Retirement is **not What You are Retiring from* *Retirement is about What You are Retiring to* --- StripMime Report -- processed MIME parts --- multipart/alternative text/plain (text body -- kept) text/html ---

2 3

[NF] Gmail Tracking
by Charles Hart Enzer, M.D. 18 May '20

18 May '20

Recommendations for Gmail Tracking? - Who - Who with multiple recipients - When - Frequency Thank you. -- *Shai / שי **Charles Hart Enzer, MD(Retired, **Ohio**), FAACAP* *Aliyah <https://app.mailtag.io/link-event-v2?mt__id=b34e893c-a4da-4b77-acb7-19613ba…>: Cincinnati to Jerusalem <https://app.mailtag.io/link-event-v2?mt__id=04498e88-d542-469d-9daa-15179a6…>'s German Colony <https://app.mailtag.io/link-event-v2?mt__id=23bd2e45-6152-489a-a24e-a957622…> May 2017* *Volunteer Associate Professor of PsychiatryUniversity of Cincinnati Medical CenterWebSite: **EnzerMD.com <https://app.mailtag.io/link-event-v2?mt__id=822d2df9-6fce-4c89-8640-551fa53…>* *Publications* <https://app.mailtag.io/link-event-v2?mt__id=5d490ca9-4e3a-4acb-8841-fb9e9af…> *Retirement is **not What You are Retiring from* *Retirement is about What You are Retiring to* --- StripMime Report -- processed MIME parts --- multipart/alternative text/plain (text body -- kept) text/html ---

2 1

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

ProFox May 2020