Verifying a field rule exist.

[preston2]

I have looked at all the field rule functions I could find in the docs and none seem to be able to return the info I need to look for.

Basically I need to check a table and see if a field rule exist in the Events/Record Events/CanEnterRecord

I know this can be done, just have not figured out how.

[Al Buchholz]

Re: Verifying a field rule exist.

http://www.wiki.alphasoftware.com/~a...LES_GET+Method

[preston2]

Re: Verifying a field rule exist.

Tried that already. Does not work.

[preston2]

Re: Verifying a field rule exist.

Getting closer but still no cigar. This returns the event rules for the field but not the record event rules.

dim tbl as P
dim fld as P
dim rules as P
tbl = table.open("wo_header.dbf")
fld = tbl.field_get("INV_ID")
rules = fld.rules_get()
?rules.Code
= CanEditField = ""
CanWriteField = ""
OnEditField = ""
OnWroteField = ""

[Al Buchholz]

Re: Verifying a field rule exist.

Not seeing a method to get it. Must be one somewhere - other then A5DOC....

Copied the structure files to a table(ddd->dbf, ddm->fpt, ddx_>cdx) and found that there is a type DRUL with the code in it.

datadict.png

[preston2]

Re: Verifying a field rule exist.

Got it.

dim tbl as P
dim tbr as P
tbl = table.open("vendor.dbf")
tbr = tbl.rules_get()
?tbr.Code
= CanChangeRecord = ""
CanDeleteRecord = ""
CanEnterRecord = 'Date Created: 01-Dec-2015 05:43:09 PM
'Last Updated: 01-Dec-2015 05:43:09 PM
'Created By  : ShopCal
'Updated By  : ShopCal
if user_level > 8 'just something to test this.
	
	end if
	
CanMarkRecord = ""
CanSaveRecord = ""
CanUnmarkRecord = ""
OnChangeRecord = ""
OnDeleteRecord = ""
OnEnterRecord = ""
OnMarkRecord = ""
OnSaveRecord = ""
OnUnmarkRecord = ""

Also just found that if you "dot" the event name after the ".code" it will return only the code for that event.
So tbr.Code.CanEnterRecord will return only the results for the CanEnterRecord event.

Cool...

[Stan Mathews]

Re: Verifying a field rule exist.

And if it doesn't exist you can add it with a variation of that code.

[preston2]

Re: Verifying a field rule exist.

And if it doesn't exist you can add it with a variation of that code.

That is the whole idea Stan.

I am going to have a table rule that is logical. Depending on the .T. or .F. result it will allow or disallow the user to be able create a new record or modify an existing.

As I know, some out there may get the big idea to remove that table rule to get around it so I will use the code above with a few more modifications in a function that will check to see if the table rule is still in place and if not, give them a big warning on the way to shutting the app down. Or I could just have the function add the rule back.

A least that is the idea anyway..

[G Gabriel]

Re: Verifying a field rule exist.

So, the idea here is if a user went and changed the field rules to be able to enter or change a record, you will, via your function (or script), prevent him from doing so?
Doesn't it stand to reason that if a user could go and change the field rules that he/she could also go and change or delete your function?
Doesn't it make more sense to deny the user any access to the Control Panel altogether?
What's missing from this story?

[preston2]

Re: Verifying a field rule exist.

So, the idea here is if a user went and changed the field rules to be able to enter or change a record, you will, via your function (or script), prevent him from doing so?
Doesn't it stand to reason that if a user could go and change the field rules that he/she could also go and change or delete your function?
Doesn't it make more sense to deny the user any access to the Control Panel altogether?
What's missing from this story?

No, they cannot delete the function. The function will be in a separate .aex file that is "Loaded" in the autoexec. Then on top of that all the scripts and functions for the app will be compiled into an .aex and then the code will be removed from the "code" tab.

Now it they want to try and create their own scripts and then delete the .aex files, more power to them but it will take them about two years to figure enough of the code out to recreate in order to get the app to even work right.

Denying the user access to the control panel does not really work if they have the developer. Even if you turn debug off so they cannot use ctrl-shift to get into the control panel, they can still get in because the debug off does not stick from one Alpha developer program to the next. I know as I have tried it.

[G Gabriel]

Re: Verifying a field rule exist.

So, the part was missing from the story is that they have the developer and you are trying to protect your own developed version from tampering.

[preston2]

Re: Verifying a field rule exist.

So, the part was missing from the story is that they have the developer and you are trying to protect your own developed version from tampering.

Basically correct G.

Most will use my apps as intended and only have the run time but because it is impossible to hide the fact that the app was developed with Alpha, some get the big idea of downloading a trial of Alpha to see if they can get around my registration system and thus continue to use the app for free.

As time goes on, I figure out more ways to close any holes that they may try and get through. I even have some scripts and functions that allow me to shut their app down over the internet. I came up with this because I had one person buy an app, got their registration number and then told their CC company they did not make the purchase. So I created what I call a jipsters function and slipped it in via a series of updates. After it had been in the app for about 3 updates, I shut his copy down and he paid me the next day.

You have to out think people who will try and scam you to save a few bucks. Besides, I love learning all this stuff anyway.

[G Gabriel]

Re: Verifying a field rule exist.

Have you tried, instead of field rules, to code the objects on the forms and password protect your forms?
Also, I am assuming you are encrypting your scripts.

[Mike Wilson]

Re: Verifying a field rule exist.

I am going to have a table rule that is logical. Depending on the .T. or .F. result it will allow or disallow the user to be able create a new record or modify an existing.

I asked myself a question years ago - "Mike, how can you hold data in a password protected environment in an application and have that data accessed and change dynamically through a script other than having data residing in an object or a table field?" The answer for me .... inside a script.

I use a script I name 'mms_registration_vault' that holds pieces of data for registration. Scripts are password protected and accessible through two other scripts using script_load() and script_save(). The contents of the vault script is something like this:

'password myimpossibletoguesspassword

<<%r%
$@$delineator$@$
verification_string===mikewilsoncompanyverificationstringa1b2c3d4e5!@#
$@$delineator$@$
registration_code===721p-d263-2030-rh07-54375422
$@$delineator$@$
%r%

The assumptions are that very few people have the capacity to break into a password protected script. They can try and delete it and rebuild it, but that is where the contents/construct of the script can be proprietary and the likelihood of a correct re-construct is infinitesimal. But I add a verification string as a first check of the contents to assure the vault is valid.

I have one script that handles collecting the registration data and writing to the vault script and one that checks the vault contents for validity and up-to-date registration. I have a navigation system in my apps, so I place a call to the registration checking script when certain critical forms are accessed. It has worked to be very robust, fast and easy. I don't worry about not letting someone have write capabilities to tables if registration is void/invalid/lapsed. I just don't let them in or I close the app if a valid registration isn't entered.

And just to have is said...I avoid using field rules as much as I possibly can.

[preston2]

Re: Verifying a field rule exist.

Have you tried, instead of field rules, to code the objects on the forms and password protect your forms?
Also, I am assuming you are encrypting your scripts.

Not sure if password protecting forms will hold if you are not using the Alpha built in security. I am moving away from that because any users that get setup are wiped out when an update is applied to the app and the end user must remember to backup users first and then restore after every update.

Also coding the object on a form means you have to do that on every form and every object on the form you are trying to stop them from doing any data entry once their trial expires. By placing the one table event rule you can shut down modification of any data used in a table app wide. So one spot and you have it covered. Then just check on start up and make sure the rule was not removed.