AEX on the server or workstation?

[betty]

Does the AEX file need to be copied to all user workstations in a runtime environment?

[betty]

Re: AEX on the server or workstation?

In fact .. are there other recommendations of things that should be copied to the local machine when setting up the network optimization piece?

[betty]

Re: AEX on the server or workstation?

Startup files belong on the workstation?

[Garry Flanigan]

Re: AEX on the server or workstation?

You are asking very general questions without detailing what you are trying to do.
An application can reside in one of many locations. For a workstation to run an application it needs only the developer or runtime install of Alpha Five on the local machine.
Depending on the situation, you may choose set-up "Network optimization", but this is not essential.
I suggest you look at Help for "Network Optimization" and "Networked Applications".

[Michael Humby]

Re: AEX on the server or workstation?

The AEX file needs to be located locally in the shadowed folder.

Michael

[betty]

Re: AEX on the server or workstation?

Thank you Michael .. that's what I was looking for ... that's where I have them installed as well as the startup files.

I did read the documentation but it wasn't clear whether the AEX should be on the server or the workstation.

[betty]

Re: AEX on the server or workstation?

I guess the real question is "To use or not use?" ..

I thought I would use the AEX file because documentation indicates that compiled code runs faster ... and I thought using the AEX file that I could simply replace one file on the server when I make a code change and that because that file is included in 'additional files' in the Network Optimize settings that it would replicate to all of the workstations.

This is what I did:
1. Make a code change
2. Recompile the AEX on my copy
3. Copy that to my test database; and it works
4. Copy that to the server at the client location (thinking it will replicate to the shadow db because it is included in the "Additional Files" list)

Nope .. doesn't seem to be working. Does not replicate to the shadow database.

So it appears that I have two choices; manually copy the new AEX file to every user's workstation (do it 10 times) or import each code change in the server copy of the database. Given those choices, I would prefer the 2nd option ... working only on the physical database on the server.

My next thought is that when I have new code to release (a function or script) I put it into a folder on the server and then have a script that gets executed via autoexec to import that code change into the database and then move it out of that folder into a history folder... so that the first user who logs on loads the new code ...

Before I go there .. perhaps I am doing something wrong ?

Thoughts? Best Practices? Throw out the AEX file?

[betty]

Re: AEX on the server or workstation?

Still on the same subject .. there are 3 ways to load a library ..

1) As an attachment to the database via FILE > DATABASE PROPERTIES > COMPILED LIBRARIES

2) VIEW > PREFERENCES > SETTINGS > AUTOLOAD LIBRARY

3) As an add-in which kind of makes it a part of alpha5 regardless of the database in use (which is not what I am looking for here).

I have tried option #1 & #2. It works on my local test database but does not work on the client's shadow database. Because you can't see its contents I can't see what's in it. Looking at time stamps doesn't help either because they all seem to be the same.

Maybe I only THINK I am using it in my test database .. maybe I should go back to that a minute ...

[betty]

Re: AEX on the server or workstation?

If I autoload a library what should I expect to see? How can I tell if I am USING a compiled library?

[csda1]

Re: AEX on the server or workstation?

Hi Betty,

There is a lot of wrong info listed above, so I just want to set things a bit straight for you and others reading.

Does the AEX file need to be copied to all user workstations in a runtime environment?

It can be loaded from the database folder, shadowed folder (normally local), as well as automatically from the Addins_Installed folder (also normally local).

If the AEX has the same name as the database and is located in the database directory, it is automatically loaded as well. If running shadowed (Network Optimized), I don't know if it uses an AEX in the shadow directory automatically (I suspect not). It might have to be loaded manually if located in the shadow directory.

The AEX file needs to be located locally in the shadowed folder.

This is untrue. It can be loaded manually from any folder, although not recommended. (By manually, I generally mean XBasic Code)

but it wasn't clear whether the AEX should be on the server or the workstation.

It really doesn't matter, and normally creates no noticable overhead on the network. However, if you had a 100 people all loading at the same time a large AEX (largest I've ever seen is 34 Meg), it may add some temporary network overhead, but this only happens when Alpha 5 starts or the AEX is loaded.

For easier support and changes, keep it in the database folder, and it will almost always never be a problem.

I thought I would use the AEX file because documentation indicates that compiled code runs faster ...

This is almost not measureable between an AEX and regular code. It is so far down in the measurement noise that it is unimportant. Loading time of an AEX may, however be important in the case of many simultaneous starts of the application (which as stated before, is almost never the case)

and I thought using the AEX file that I could simply replace one file on the server when I make a code change and that because that file is included in 'additional files' in the Network Optimize settings that it would replicate to all of the workstations.

That would work fine, although, again, the need to copy it to the workstations may not gain you much advantage.

A couple of things. In order to use the AEX, the adb functions/scripts you created in the database must not be there, otherwise they will override the AEX versions. To find out what AEX's are loaded and their locations, you can use the CSDA DiagInfo utility, which will report the loaded AEX's and their locations.

If you have more than one loaded, you will need to remove all but one to test if it is working. Just test a simple function in one of the AEX's to determine if it is present. If it returns a simple string, it can report the version number, e.g.

function _AEXVersion as C()
_AEXVersion="1.20"
end function

I tend to use a standard of an underscore followed by the AEXName as a standard name to return a version #

There are XBasic commands to load and unload a library, which can also be done in the Autoexec

Note which AEX library number you are using. See my tips here.

Also see the tip on Network Optimization here.

I guess the real question is "To use or not use?" ..

As to whether to use or not, I would generally say no unless you are trying to protect intellectual property or client tampering.

To update an data dictionary with new code, you could just export the code from a development copy and import it to the live copy. This gets rid of the issues about other changes to the alb, alx, and alm files (although you can often just overwrite them with the new copy - Depends on whether you are using Imports and a few other operations and other objects stored in those files).

Hope this straightens things out.

[MoGrace]

Re: AEX on the server or workstation?

I've been back to this thread several times and it does not seem that an aex with the same name as the database, residing in the shadowed folder or on the server, works with the runtime version - at all. When I load the server with a full licensed copy of Alpha it works. Also when I run the shadow copy with the full license version it works. What doesn't work is loading either copy with the runtime - my compiled functions are not being recognized with the Autoexec throwing the first error.

What else could be going on, or am I just not understanding how to do this with runtime? Also there is no 'addins installed' folder included with the runtime, else I would try that!

[MoGrace]

Re: AEX on the server or workstation?

Just a bump in case any one can advise on this?

[Michael Humby]

Re: AEX on the server or workstation?

Robin,

This may be the 'Bump' that you need.

Are the folder attributes on the server hidden by Windows? if so this may be the answer to your problem, the attached error occurs V10 and V11 and the dbase gets broken!! (however V9 is OK)

We have lots of users with RDP to our remote servers and obviously we must hide folders between users.

You can create this test on your own PC but beware because it will break your application so make sure that you have a backup that you can restore.
Picture0001.png
(the staffblank.dbf mentioned in the error holds the opening form)

You can use Alpha Sports as your test if need be

1. Create a temp folder and place your application inside then open the app to confirm OK

2 Right click the folder and choose Properties then click the 'Hidden' attribute then OK and accept the default to include sub folders.

3. Now try to open your app again with V10 or V11 you will see that it is broken, even if you remove the hidden attributes from the folder, and the only way that I know to fix is to restore the dbase files from a backup

My remedy is, when applying the hidden attributes NOT to include subfolders and then hide the subfolders independently if need be.

Michael