How to instantiate a class contained in DBC stored procedure.

[CoreMemory]

Hi All,

If you have a custom class defined in a stored procedure in an open database, is there a way to force CREATEOBJECT or NEWOBJECT to find the class.

SP code:

DEFINE CLASS  myclass CUSTOM
 PROCEDURE init
 LPARAMETERS p1,p2
..
ENDDEFINE

----------------

Neither

omyclass=CREATEOBJECT('myclass',p1,p2)

OR

omyclass=NEWOBJECT('myclass','','',p1,p2)

will find the class so it can be instantiated.

With NEWOBJECT what would you put in the cModule name to cause it to search the stored procedures for the class?

yet if I add a wrapper function to my stored procedure

FUNCTION DoMyclass(p1,p2)
  omyclass=CREATEOBJECT('myclass',p1,p2)
  return omyclass
ENDFUNC

DEFINE CLASS  myclass CUSTOM
 PROCEDURE init
 LPARAMETERS p1,p2
..
ENDDEFINE

It works fine when I use the wrapper which does the CREATEOBJECT from within the stored procedure.

Am I missing something obvious here?

TIA,

Tom

 

[Mike Lewis]

Tom,

I've never heard of this being done, and I'm not sure it if is possible. The Help for Newobject() makes no mention of stored procedures being on the search path for the class definition, nor does it mention stored procs in the module name parameter. Same with CreateObject().

Just out of curiosity, why do you want to do this?

Mike


Mike Lewis
Edinburgh, Scotland

http://www.ml-consult.demon.co.uk

 

[ramani]

HI

Just my experience..

I dont know how many will agree with me, but I have found circumstances (a poor hardware for example) when a stored procedure has failed to respond and causing consequent database failures (may be the autonumber routine failed etc.). After hesitation, it just took me a minute to copy all the stored procedures and shift it to the end of my Main.Prg.
From that time onwards I did not face any problem. SO I continued that method and never made any stored procedures.

An additional advantage I gained is that, as time progrssed I started making distributed application methods to use common server data. Meaning to say, that as and when I upgrade my software, all users get updated automatic to their desktop and run from that copy. Now, that the Main.Prg is also incorporated, the load on the server is much less. The distributed application has the so called stored procedures gets an advantage as well.

Is there any reason, we have to use stored procedures?. The triggers work anyway even with the routines available from the Main.Prg. SO I find this more convenient.




ramani
(Subramanian.G)

http://winnersoft.coolfreepages.com/

 

[CoreMemory]

Hi Mike,

Thanks for quick reply.

Trying to explore the possibility of replacing the classes at different sites with different versions without having to replace the .exes that use them.

Our main .exe actually use the RUN command to fire up our modules so they are separately executing programs. Their common link is the stored procedures that contain loads of functions that are common to them and are not subject to being changed.

However, there are some classes that I want to allow variatations on at the sites. I don't want to have to continually replace all the .exes just because one of the classes is being changed and is being used by all .exes.

BTW, when I use the wrapper function and look at it in the debugger I notice the classlib name is c:\data7\site.dst which is where the stored procedures are contained.

Yet, I cannnot use the 'c:\data7\site.dst' value as the name of the cModule in the NEWOBJECT function.

Have also tried SET PROCEDURE TO c:\data7\site.dst and that did not help also.

Acutal error is 1733, Class Definition not found...


Tom

 

[CoreMemory]

Hi Ramani,

We actually are not using the stored procedures for trigger logic, just a bunch of functions that are common througout the application. They need to be fast and we find that they are, since the stored procedures are loaded and kept in memory (if my understanding is correct) and do not need to be interpreted from the VFP pcode each time they are used.

Probably biggest reason for using the stored procedure is that there are muliple main programs (one for each .exe) in our application. Changing class code in each one would require them all to be rebuilt and redistributed, even if it was just a minor change

We already have many classlibs that are common to each of the .exes. They get updated and rebuilt when new .exes need to be distributed. We already have a stub 'loader' program installed on each user machine and its replaces the user's copy of the .exes as they updated at the sites.

One other thing I tried was

omyclass=NEWOBJECT('myclass','mymodules.prg','c:\mymain.exe',p1,p2)

This works if I use it from a method within mymain.exe, but produces the 1733 error when I use it from a myapp1.exe that was launched with a RUN /n myapp1.exe from the mymain.exe.

Thanks for your response,

Tom

 

[ramani]

HI

I dont know if this could solve your problem.
*********************************
FUNCTION myClass
PUBLIC oForm
oForm = NEWOBJECT("myForm&quot
RETURN
****************************
DEFINE CLASS myForm AS FORM
PROCEDURE init
** Your code
ENDPROC
ENDDEFINE
********************************

Now by code , you can call it..
=myClass()
oForm.Show
RELEASE oForm

I have not tested this well. The idea is to create the object from with the function call and then return a reference to the object..



ramani
(Subramanian.G)

http://winnersoft.coolfreepages.com/

 

[Mike Lewis]

Tom,

So, if I've got this right, your aim is to have a way of distributing relatively small bits of code without having to redistribute the entire application?

One alternative would be to put the code into a PRG, and to build it into an APP file. Your main application can then DO the APP file, which will get all the function or class definitions into memory.

I'm not clear if you want to give your users access to the source code. If so, another possibility might be to distribute the code as PRGs, and to use the new ExecScript() function to execute it.

Mike


Mike Lewis
Edinburgh, Scotland

http://www.ml-consult.demon.co.uk

 

[CoreMemory]

Mike,


"One alternative would be to put the code into a PRG, and to build it into an APP file. Your main application can then DO the APP file, which will get all the function or class definitions into memory."

That would probably work ---even though I would have to DO LoadClasses.app or whatever in each of the modules not just the main. The modules get launced as separate .exes from the main .exe, they do not share memory space. We corridinate the various .exes through API calls.

Will give it a try and let you know how it works.

Thanks again,

Tom

 

[CoreMemory]

Ramani,

"The idea is to create the object from with the function call and then return a reference to the object.."

oForm=myClass()
oForm.Show
RELEASE oForm

Yes, that works....just was trying to let the class defined with the

DEFINE CLASS myForm AS FORM
PROCEDURE init
** Your code
ENDPROC
ENDDEFINE

to be able to be located in stored procedures and yet be found by oform=CREATEOBJECT('myForm')

I will try Mike's suggestion for locating the classes into an .app file and then making it available by using a DO command from the init event of each of the .exe modules.

Thanks again,

Tom