Alternative to SELECT 1 to check MariaDB Server online status ( using DO 1 generates an error )

[dylim]

Hi Guys,

With MySQL, I use "DO 1" to check for the server's online status. Works like a charm. But MySQL 8.x has caused me so much pain by way of unknown errors I cannot seem to understand and correct.

So, I tried MariaDb, installed the latest GA todate, 11.7.2 and used the latest ODBC 3.2.5 32 bit.

None of the horrific problems came out! What a joy! And so far so good. It's even way way faster!

I have since been testing MariaDb, hoping to use this as my new go to database server.

So far, my only issue now is that MariaDb returns an error when I use "DO 1" in checking for online status. I have to use "SELECT 1" in lieu of this. What I don't like about this is it returns a cursor which I need to erase each and everytime I check for online status.

Any other commands like DO 1 that do not return a cursor?

Thanks in advance! Long live the Fox!

 

[dylim]

You could likely get further with MySQL usinag VFPA 64bit and overcoming that aspect of it, enabling to use 9.x drivers. Not sure VFPA has advanced it's runtime general ODBC capabilities. When it comes to SQLEXEC, it's not a direct step from VFP to the ODBC driver, the basis is still how VFP communicates with an ODBC driver and that can break with newer versions of ODBC itself, also within the 64bitness of VFPA.

That is going to be my next level up. Have you tried dabbling into VFPA 64 bit sir? If so, any feedback favorable or otherwise? I read somewhere that modules like VFPEncryption.FLL and FoxyPreviewer.app will not run anymore? (this is a bummer; are there alternatives to these that you know?)

Am now working on a Payroll system. Next in line also is how to programmatically generate individual PDFs for employee pay slips then email them one by one. I currently do REPORT FORM for the pay slips then tell the users to print to Microsoft PDF Printer.

Cheers! Thanks!

 

[Chriss Miller]

I didn't use VFPA, let others tell you about that.

Mainly an FLL is a DLL, but with some aspect of a srtructure that makes it compatible with the VFP command SET LIBRARY to load such a special DLL and all its functions and provide them without need to use the DECLARE DLL command. There's a bit more to it as the major component winapims.lib allows you to use several predefined functions that implement some behind the scenes C structures used in VFPs own development into the FLL projects. In short, this is nothing you can use as a VFP developer without C knowledge, that part only regards the C/C++ developer developing the FLL. But the restriction coming with it is that it's all 32bit, again.

An FLL can require another C++ runtime than VFP.exe or EXEs you build with VFP and still works, you just need to provide multiple C++ runtime DLLs, so you can build FLLs with latest versions of MS VS C++ and also use them in VFP9, as long as you build 32bit FLLs. Or you build 64bit FLLs for use with VFPA 64bit.

I know the VFPA developer also upgraded the components coming with VFP9 that you need to build an FLL to 64bit. So you could in theory also build FLLs in 64bit versions, but you can obviously only use a given FLL as is and 32bitness will make that unavailable to use with VFPA 64bit. There are alternatives for encryption, but involvement with specifically VFPEncryption.FLL means dependency on VFP9 or VFPA 32bit and you can't at the same time use 64bit ODBC drivers.

Rewriting all the stuff unless you get hands on the FLL developers to upgrade their FLLs with the upgraded winapims.lib. It's not likely to happen, especially with Craig S. Boyd, I think. I don't have heard of any well known FLL to be ported to 64bit, yet, but the path to that is available.

Rick Strahl is the only one I've heard of explicitly not testing for VFPA compatibility of his components like Web Connection, .NET Bridge and more. So that's also stuck with 32bit unless Rick Strahl changes his mind about that. But as long as it works, it works. Again, there's mostly VFP code that's portable. I know there are some DLLs involved with Web Connection and .NET bridge that would make it depend on 32bit, once more.

But any component that's built from VFP sources is also available for VFPA64bit, I don't know from where you got the report apps are not able to run with VFPA, VFPA comes with the report.apps, and the sources of these apps are part of VFP.

I'm not even sure the APP files need a rebuild, they always run in the context of an EXE and use the corresponding VFP runtime dll, they're not running their own process, an APP is only VFP byte code, not an executable, so it's not compiled for any platform, compatibility issues can only be in versions of the runtime DLLs not supporting certain VFP byte code in the apps, so that just means you can't run an APP using a command or function only available in VFP9 and run it with a VFP6,7, or 8 runtime DLL. But indeed you can build an APP with VFP9 that only uses commands older versions also support and can use the app in an older VFP version, too. That's the nature of byte code, for existing unchanged commands and functions the byte codes also remain as they were. They don't even change with bitness.

 

[Chriss Miller]

ell the users to print to Microsoft PDF Printer

Tell VFP that:

Set Printer To Name "Microsoft Print to PDF"

Done.

More generally speaking, APRINTERS gives you a list of printer names as VFP knows them and can use them for SET PRINTER TO NAME including the spaces, as that printer name demonstrates, also works with a variable name like this:

lcPrintername = "Microsoft Print to PDF"
Set Printer TO Name (lcPrintername)

 

[dylim]

Tell VFP that:

Set Printer To Name "Microsoft Print to PDF"

Done.

More generally speaking, APRINTERS gives you a list of printer names as VFP knows them and can use them for SET PRINTER TO NAME including the spaces, as that printer name demonstrates, also works with a variable name like this:

lcPrintername = "Microsoft Print to PDF"
Set Printer TO Name (lcPrintername)

How about custom page sizes like maybe a special paper for pay slips? If we set them at our VFP REPORTS designer, will this be complied with when "Microsoft Print to PDF" is used?

Thanks.

 

[Chriss Miller]

When user pick the printer and it works, then SET PRINTER NAME does nothing else and it also will work. It's the same thing, just done by code instead of a human. And if they also change format setttings etc. there's the correpsonding thing to do, in the simplest case adding the PROMPT clause to REPORT FORM will prompt for printer choice inclusing access to format and other options.

You will surely find advice, if you search the form for recommned wayas to use Prionter settings with VFP. There's nothing that's new to this, the best is to have a preconfigured printer by name that can be based on anything also on PDF printers. A report I think can mainly pick portrait vs landscape, otherwise printer settings are mainly defining the format of pages. and whether paging is done at all, a counterexample is POS receipt printing on endless paper with varying receipt length that's never causing page feeds and ends the format with a paper cut, not by report format/margins etc.