problems porting app to server to create runtime

[Kellen Furness]

I'm counting on you all being brilliant, as usual.

We're having problems porting our app to the server to create a runtime app. We did the same process only a week ago and it worked fine (same alpha build, same app, same directory structure, same porting process, etc.). I've added some tables, forms and reports since last week, but nothing that I would expect to impact the opening of a db. My partner called tech support, but was advised to post a message to the phorum, so here it is.

I created an app on my laptop, using A5V5 full version, build 1506. It runs very nicely on my laptop. I then zipped the app using Alpha's zip tool. My partner unzipped the file on the server (our goal is to create a runtime app and the server is where we have both the development and runtime versions).

Below are the problems we are experiencing BEFORE even attempting to create the runtime app. We tried re-zipping the app and reinstalling on the server. We also tried copying my entire development directory over to the server, but continue to have the same problems.

1.logon dialog failure
The xdialog box never pops up to request login.

2.autoexec failure
The app doesn't seem to run my autoexec script, which hides the control panel for most users, loads some global variables from a setup table, etc.

3.repeating menu bar
The top Menu Bar repeats 6-7 Times across the top of the screen.

ANY SUGGESTIONS? PLEASE HELP! Thanks.
-Kellen Furness

[Tom Henkel]

RE: problems porting app to server to create runti

Questions before suggestions.

What OS is on the laptop? What OS is on teh Server?

How are you connecting?

Did you set appropriate permissions on the server?

Alpha EXPECTS to have full permission to add, delete, and modify files. If the server hs not granted you (as a user) full access to the folder and/or tables, you will be out of luck.

Can full Alpha open the control panel of the database on the server?

Are any of the tables or sets "grayed out"?

Did you set proper shared database path in the runtime?

That should be enough to get you started. With answers, we may be able to help you alon the way.

Tom

[Kellen Furness]

RE: problems porting app to server to create runti

Thanks for the reply, Tom. The answers to your questions...

Laptop OS is Windows XP Home.
Server OS is Win 2000 Advanced Server.
Connecting direct/cable. CAT5 Network.
Logged into server as ADMINISTRATOR when doing this.
Alpha CAN open the control panel of the db on the server.
NO tables or sets "grayed out".
I cannot even launch the db properly; I haven't created (and can't create) the runtime.

I look forward to hearing your ideas.
-Kellen

[Tom Henkel]

RE: problems porting app to server to create runti

If I am hearing you correctly, you want to execute Alpha5 on the server. I don't recomend this unless you can guarantee that you won't ever lock up the server, else all your users will be stuck.

I recommend that you install the full version on a workstation and only your database on the server. Set full access permissions and security to all users on the server folder containing your database. Map the server's drive to your workstation and work from there. Install runtime on every workstation that needs access, and map the server drive to those workstations as well.

We have a very large network of users, and the only time we actually bring Alpha 5 up on the server is at night to do "batch" runs on our tables. Our server basically is just a file server. On your workstations, make sure that the data paths in Alpha5 are consitant.

hope this helps.

Tom

[Kellen Furness]

RE: problems porting app to server to create runti

Hi Tom,

I understand your assumptions, but it's not quite right. Our end users are remote (gas stations), so we do provide access via Windows Terminal Services for some applications running on the server. We do NOT plan to do this with our Alpha applications, however, for the reason you stated, as well as to maximize processing speed. ALSO, although the end users have the same basic data profiles, only we at the head office care about the aggregation and manipulation of the data since we provide reporting to the gas station ownership. So...

We have runtime installed on our server merely because that's the computer we intend to use to create the executables. It's my understanding that you must have both the development and runtime versions installed on the computer where you create the executables. True?

We intend to install Alpha runtime at each gas station and provide each station with their own executable. They will run the app locally and store their own data locally. We will use PCAnywhere to poll at night for data updates and merely copy that data to our server tables for data aggregation, comparisons, etc. (all data tables include a location_code unique to each station).

Does this scenario make sense with Alpha? Does it help explain the problems we're having in launching the app on the server (even prior to attempting to create the executable)?

Thanks,
Kellen

[Tom Cone Jr]

RE: problems porting app to server to create runti

Kellen,

You write:

We have runtime installed on our server merely because that's the computer we intend to use to create the executables. It's my understanding that you must have both the development and runtime versions installed on the computer where you create the executables. True?
---------------------------------------------------------

Using vers 4 of Alpha Five this is NOT true. I don't have experience with vers 5 of the Runtime, but would be very surprised if it were true with it, either.

For the typical office LAN the development machine contains the full version of Alpha Five. The app is built and tested on this machine.

The app (the database) is then copied to a shared folder on the machine which will act as file server to the workstations.

The runtime engine is installed on each workstation but NOT the server.

The runtime engine opens the database on the server over the network, and optimizes it back to the local workstation. Thereafter the runtime engine runs the shadow copy of the database which is now resident on the local workstation.

-- tom

[Kellen Furness]

RE: problems porting app to server to create runti

Thanks, Tom, but it sounds like this is a different scenario than what I described above (although it will be useful info if we start using alpha for internal office db's). Our current situation is that our end-users are off-site, even in different states (as in MD/VA, not a computer state reference).

Any comments/ideas on my original problems, which prompted me to start this message thread in the first place?

Should we try calling tech support again? Or is it standard Alpha practice to refer all tech questions back to the phorum?

thx,
Kellen

[whanigsberg]

RE: problems porting app to server to create runti

Kellen,

Check me on this. Your situation is simple. The network is irrelevant:
-You just copied your application from the laptop to the server.
-You installed A5 (full-forget the runtime for the moment) on the server.
-You then sat down in front of the server and ran A5 (this renders the network irrelevant)
-When you attempted to navigate to your application (from within A5) and open it you got your problems.

If you didn't do this try it and report back with the results.

Otherwise, forget about the A5 zip utility and use winzip to transfer your application to the server and try what I suggested above.

Also, if you transfer your application to yet another computer do you get the same results. If so, your application may contain absolute paths.

Have you compacted your application on the server?

If I have totally misunderstood what you have done please correct me.

Bill

[Tom Henkel]

RE: problems porting app to server to create runti

Alpha can easily do what you want. I think you would probably want a slightly different app at the server side than at the local gas station. as your information needs will be greater than the local station's. The pollong really has no bearing on Alpha. That should only pull information from one remote location, place it into a folder known to the server app, run the server append, then go on to the next station.

I would create a blank table that looks like thetable on a remote system, atach itto the server database, then during your polling sequence, first initialize the table to make sure it is blank, then poll the station to populate the table, finally, append the data into your main server table.

Once done with station 1, do the same for all other stations in sequence.

All that said, I think bill may have hit on an issue of absolute pathing. Your server will have different permission levels and security than a stand-alone machine, even for someone connecting at the console.

tom

[Kellen Furness]

RE: problems porting app to server to create runti

All-

I am trying all of your suggestions and researching topics you've mentioned with which I'm not familiar. Thanks for your time. I'll write after I've followed through with your suggestions.

-Kellen

[Kellen Furness]

RE: problems porting app to server to create runti

Problem remains (DB not requiring login and not playing autoexec script):
The top theory seems to be that my problem is being caused by absolute paths. After lots of phorum research, I still don't know how to avoid absolute paths. I did NOT check this option when I used Alpha's zip tool and I've even gone so far as to copy my entire directory over to the server without zipping at all. I also read that absolute paths are created for any tables that reside outside of the db folder, but I have everything in the same folder (well, everything except for the zip file, but as I mentioned above, I also tried transferring the files without zipping). Is there any way to verify that this is the problem? Or insight on other ways that absolute paths are created without my explicit request?

Repeating menus:
This problem went away after compacting the db. Thanks for the tip, Bill Hanigsberg

Polling remote locations:
Tom Henkel's suggestion on polling process is an improved version of what I had planned to do-thanks.

-Kellen

[whanigsberg]

RE: problems porting app to server to create runti

Kellen,

Regarding absolute paths, if--within your application--you write code specifying an absolute path, that code will fail when your application is copied to a machine where that path does not exist.

So it's not primarily a zip file issue; it's a design issue.

Bill

[Tom Henkel]

RE: problems porting app to server to create runti

Kellen,

Is it possible that you could post the DB up to the forum?
Maybe if one of us took a look at what you were doing, we could be of more help. Something seems to be happening right at startup to prevent you from signing in.

Tom

[Kellen Furness]

RE: problems porting app to server to create runti

I'm reluctant to post the DB here since it contains proprietary data for the first gas station that will implement it. As an alternative, could I send the DB directly to one or two of you and pay you as a consultant to do the review? Once you determine the problem, one of us could post a description of the resolution for other interested phorum readers.

-Kellen