Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations Rhinorhino on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
NETWORKING VFP EXE
- Thread starter dexterdg
- Start date
Olaf Doschke
Programmer
What exactly are you trying to achieve? Data on a network share? Then simply put it there and SET PATH to it and vfp will get data from there.
Also see
Bye, Olaf.
Also see
Bye, Olaf.
More detailed suggestion (sorry, Olaf!):
1. Create a Config.FPW file if you haven't done it yet
2. Place it in the same directory with your EXE (on an individual WS's or on the root data one on the FS - regardless)
3. Put in this Config fiel the following line:
Here's the typical Config.FPW yours truly have been using for decades for distribution with the EXEs:
HTH.
Regards,
Ilya
1. Create a Config.FPW file if you haven't done it yet
2. Place it in the same directory with your EXE (on an individual WS's or on the root data one on the FS - regardless)
3. Put in this Config fiel the following line:
Code:
COMMAND="SET PATH TO < Your Full Path to the Data Directory> ADDITIVE"Here's the typical Config.FPW yours truly have been using for decades for distribution with the EXEs:
Code:
TITLE=""
CENTURY=ON
SAFETY=ON && I set ot OFF in the code
DELETED=ON
MVCOUNT=64000
STATUS BAR=ON && I set ot OFF in the code, if needed
HOURS=24 && My personal preference
SECONDS=ON && My personal preference also
CPDIALOG=OFF
RESOURCE=OFFHTH.
Regards,
Ilya
Not so much from an over-all performance perspective, but from a Maintenance perspective I have found that rather than having separate copies of the PrimaryApp.EXE on each and every individual workstation, it has worked better for me to have the PrimaryApp.EXE on the server itself and to use an Application Launcher to launch it.
That way I could make modifications on the PrimaryApp.EXE and do re-compiles if necessary without having to run around and either get all my clients out of the PrimaryApp.EXE (if on the Server) or to update their workstations (if on the workstations).
The 'Launcher' that I have used is:
faq184-4492
with only a few modifications.
Good Luck,
JRB-Bldr
That way I could make modifications on the PrimaryApp.EXE and do re-compiles if necessary without having to run around and either get all my clients out of the PrimaryApp.EXE (if on the Server) or to update their workstations (if on the workstations).
The 'Launcher' that I have used is:
faq184-4492
with only a few modifications.
Good Luck,
JRB-Bldr
Olaf Doschke
Programmer
Ilya, it's good you extend what can also be put inside a config.fpw. I rather prefer to set anything but SCREEN and RESOURCE in the EXE, because these are the only things influencing start before even your first line of code runs.
Eg you can also set _SCREEN.Visible = .F. to hide the screen, but it would flash for a split second, SCREEN=OFF in config.fpw hides the screen from beginning on. REOURCE = OFF causes no foxuser.dbf to be created, which is also something needing suppression before you can intervene.
It's a matter of taste what else you put into config.fpw. If you keep it a seperate file you can of course offer your users to adapt the settings to their needs.
One more note about SET PATH: If you work for the company for which you develop your app, your develop machine may be in the same network as your users. You developed with data local? You developed using the dataenvironment of your form?
Then the exe put elsewhere will not see the data anymore, dataenvironment harcodes file locations, but the SET PATH setting will solve that, as you can add any amount of paths VFP will also search for files it doesn't find. So even if you "hardcoded" the location of your DBFs via putting them in the dataenvironment of forms, this setting can unbind you from that location. That's how that setting saves you.
Copying the data into a network share and SET PATH will let other users access the network data. But the exe on your computer will still find the data at the original position. Just rename the development database folder, then you'll also be redirected to the network data. Otherwise you will be using your local data and only other users will be redirected to the network path you should set in SET PATH. You could also see this as a pro instead of a con, because you can continue to develop without changing the production data.
So you see, there are at least two different problems to solve about networking an application: 1. putting data central and 2. putting the application itself into the network.
I can't smell what you mean by NETWORKING your exe. You have to tell us, what you want to achieve.
Bye, Olaf.
Eg you can also set _SCREEN.Visible = .F. to hide the screen, but it would flash for a split second, SCREEN=OFF in config.fpw hides the screen from beginning on. REOURCE = OFF causes no foxuser.dbf to be created, which is also something needing suppression before you can intervene.
It's a matter of taste what else you put into config.fpw. If you keep it a seperate file you can of course offer your users to adapt the settings to their needs.
One more note about SET PATH: If you work for the company for which you develop your app, your develop machine may be in the same network as your users. You developed with data local? You developed using the dataenvironment of your form?
Then the exe put elsewhere will not see the data anymore, dataenvironment harcodes file locations, but the SET PATH setting will solve that, as you can add any amount of paths VFP will also search for files it doesn't find. So even if you "hardcoded" the location of your DBFs via putting them in the dataenvironment of forms, this setting can unbind you from that location. That's how that setting saves you.
Copying the data into a network share and SET PATH will let other users access the network data. But the exe on your computer will still find the data at the original position. Just rename the development database folder, then you'll also be redirected to the network data. Otherwise you will be using your local data and only other users will be redirected to the network path you should set in SET PATH. You could also see this as a pro instead of a con, because you can continue to develop without changing the production data.
So you see, there are at least two different problems to solve about networking an application: 1. putting data central and 2. putting the application itself into the network.
I can't smell what you mean by NETWORKING your exe. You have to tell us, what you want to achieve.
Bye, Olaf.
- Thread starter
- #6
aim:
[li]to be able to work myapp.exe into different units(network it) having a server-client structure wherein the data is kept on the server.[/li]
what i have:
[li]form,dbf,scx,vcx,mpr,pjx(stuffs i used to create myapp.exe)[/li]
[li]myapp.exe[/li]
[li]an existing LAN connection[/li]
[li]an existing server-client relation bet. units[/li]
is this what you mean sir olaf?
Dexter
[li]to be able to work myapp.exe into different units(network it) having a server-client structure wherein the data is kept on the server.[/li]
what i have:
[li]form,dbf,scx,vcx,mpr,pjx(stuffs i used to create myapp.exe)[/li]
[li]myapp.exe[/li]
[li]an existing LAN connection[/li]
[li]an existing server-client relation bet. units[/li]
is this what you mean sir olaf?
Dexter
Olaf Doschke
Programmer
A "networked app" also can mean many users use an app, which is installed completely on a server, not only it's data, it can also mean distributed computing and more.
What you are describing is known as programming for multiple users and shared data access.
Well, then you have your answer in the chapter about making an application multi user capable by programming for shared access.
And the main thing to do is nothing, because mainly you will need to open data shared instead of exclusive, but shared usage of DBFs is the default, so from this perspective your exe is already network ready.
The other thing I would need to know is how you programmed data acceess. If you visually added tables to form dataenvironment you have hardcoded paths to the database. Renaming the original folder with your data will make your EXE error, as it doesn't find the data at the paths encoded in dataenvironment properties and the properties of the visually embedded tables.
Adding a SET PATH statement to point to a network share will make VFP look there before it gives up, erroring. This is what I was explaining twice already. So Ilya's additional line for your config.fpw would make your app work "networked".
But you also have to consider the side effects of shared data access, concorrent use of table and concurrent update of same records. All this is explained in detail in the link I gave you, which is just the introductory page for the whole chapter of the foxpro help.
I don't know what else you think you need to do with your exe or need to know, perhaps start with trying out the code and tips we gave you already, or ask about them specifically, if you don't ubderstand them. I can't offer you more than that. I can't help you more to grab the answers already given here.
Bye, Olaf.
- Thread starter
- #8
-No Visually Added table/s on the data environment[form & report]. instead, i created cursors
--Does this : makes any future error/s?
Concurrent use of tables
-setting Shared ON of tables : w/c is default
--Does this solves : having an error when accessing the table when more than one workstation uses the same table at the same time?
Concurrent updating of records
-i've used buffer. locking of tables/records, i used: replace, delete-sql, append blank, tableupdate, insert-sql. these have auto locks.
--Does this solves : manually locking and unlocking of records/tables and no more public data session -> private data session needed? will i still be required or is it optional to add the trapping errors guide on the foxpro guide for managing buffer conflicts? where/when will i put it?
User collision is what you have stated and is rare(having a deadlock) according to the guide but i wont depend on that. and i cant still apply it yet. my request for the usage of the units is still pending because they use the units everyday - sorry.
What i have done for now is added what Ilya said. If thats all about it(with the collision and "network" by Ilya) Thanks so much!
I'll update this for the result when i applied it
Thanks
Dexter
Olaf Doschke
Programmer
I don't understand why you have that questions. Your questions show a lack of understanding, which is he reasons for questions, but your questions even show a lack of understanding what to ask or a totally different understanding of how things should work. Where do you come from, which other database or languages did you use? I think you have to forget some concepts you already know, which are not at all valid for Foxpro.
So this reveals a lot more to answer to than just asking how to network an app. Keep going in that direction.
If you didn't used the dataenvironment of forms that's fine. So how did you create cursors? Via SQL-Select INTO Cursor, via Views?
Both of these for example would just depend on an OPEN DATABASE yourpath.yourdatabase.DBC and that would be the only line you would need to change, when you move data to the LAN. And even that only, if you devloped using a local drive for data. If you even started putting the data in a LAN shared folder then nothing is to change in pathing.
SET EXCLUSIVE OFF (not SET SHARED ON, this doesn't exist) solves usng data shared, yes. With SET EXCLUSIVE ON only the first user will be able to open a DBF, no matter if via dataenvironment USE, View, SQL, all of these open a DBF to start with and do so shared or exclusive.
SET EXCLUSIVE OFF is the default, so there is NOTHING TO DO with this, this is just something you should keep in the head for times you need exclusive access.
If you INSERT INTO TABLE that has no potenial of conflicts, as it always creates new records, if you UPDATE TABLE instead of using TABLEUPDATE() to commit changes, that also has no potential of conflicts, as the SQL-Update doesn't take OLDVAL() and CURVAL() of fields into account, it blindly updates whatever is in the record disregarding what was there when user/workstation started editing. That concept of conflict detection is not part of SQL. If you do SQL-UPdates this, then you don't make use of buffering, as you say or think.
Private vs. Public data session don't make a difference like private and public variables or methods do, this has not the full and same OOP meeaning of these terms. Private data sessions just means a form creates a new datasession, in which no table is opened at start. Any other form can use ASESSION() giiving an array of currently open data sessions and then SET DATASESSION to another private datasessin and work there. That's not the intention of private datasessions, but it shows they are not that private and protected as variables would be. The reasoning for private datasessions is just to have a fresh new session and be able to CLOSE ALL without affecting other forms running in parallel, for example. You can move to other records than a parallel form, so this is nice for a situation you have a list form showing a list of records and a detail form showing one record in detail. If that detail form reopens a table in a private datasession you can move to a certain record and display it, and you can then start 2,3, N such detail forms in parallel all having their own datasession with their own record pointer to their record. Reusing the current datasession each new detail form would move the record and all detail form would show the same record of the last opened detail form. There you have a good usage for private datasessions. You can also use the ALIAS clause or cursor naming, and USE AGAIN, to do all this in one datasession, but life is much simpler having seperate data sessions.
Bye, Olaf.
So this reveals a lot more to answer to than just asking how to network an app. Keep going in that direction.
If you didn't used the dataenvironment of forms that's fine. So how did you create cursors? Via SQL-Select INTO Cursor, via Views?
Both of these for example would just depend on an OPEN DATABASE yourpath.yourdatabase.DBC and that would be the only line you would need to change, when you move data to the LAN. And even that only, if you devloped using a local drive for data. If you even started putting the data in a LAN shared folder then nothing is to change in pathing.
SET EXCLUSIVE OFF (not SET SHARED ON, this doesn't exist) solves usng data shared, yes. With SET EXCLUSIVE ON only the first user will be able to open a DBF, no matter if via dataenvironment USE, View, SQL, all of these open a DBF to start with and do so shared or exclusive.
SET EXCLUSIVE OFF is the default, so there is NOTHING TO DO with this, this is just something you should keep in the head for times you need exclusive access.
Yes.
There's no need to manually lock, that's right, but even if you only make use of automatic locks you could have conflicts. What you say you make use of is buffers, that means you will commit buffer changes at some time concentrated, and every change made inbetween from starting to edit to committing changes has the petential to cause conflicts, if other workstations changed same records. And this is not about the conflict you could have at concurrent changes at the same split second, but on the scale of how many minutes users edit, before they save.
If you INSERT INTO TABLE that has no potenial of conflicts, as it always creates new records, if you UPDATE TABLE instead of using TABLEUPDATE() to commit changes, that also has no potential of conflicts, as the SQL-Update doesn't take OLDVAL() and CURVAL() of fields into account, it blindly updates whatever is in the record disregarding what was there when user/workstation started editing. That concept of conflict detection is not part of SQL. If you do SQL-UPdates this, then you don't make use of buffering, as you say or think.
Private vs. Public data session don't make a difference like private and public variables or methods do, this has not the full and same OOP meeaning of these terms. Private data sessions just means a form creates a new datasession, in which no table is opened at start. Any other form can use ASESSION() giiving an array of currently open data sessions and then SET DATASESSION to another private datasessin and work there. That's not the intention of private datasessions, but it shows they are not that private and protected as variables would be. The reasoning for private datasessions is just to have a fresh new session and be able to CLOSE ALL without affecting other forms running in parallel, for example. You can move to other records than a parallel form, so this is nice for a situation you have a list form showing a list of records and a detail form showing one record in detail. If that detail form reopens a table in a private datasession you can move to a certain record and display it, and you can then start 2,3, N such detail forms in parallel all having their own datasession with their own record pointer to their record. Reusing the current datasession each new detail form would move the record and all detail form would show the same record of the last opened detail form. There you have a good usage for private datasessions. You can also use the ALIAS clause or cursor naming, and USE AGAIN, to do all this in one datasession, but life is much simpler having seperate data sessions.
Bye, Olaf.
- Thread starter
- #10
[li]oh im sorry. i didnt mention i did not use database. all free tables[/li]
[li]....so i didnt catch up to the "pathing thingy" i just used "USE TBL_TBLNAME" should i still put c:\path\path\tbl_tblname.dbf? [/li]
[li]i agree with the lack of understanding. im something like a student learning vfp. i used both buffering and sql-update, buffering so i can browse over the records with first, next, prev, last. sql-update for adding records coz its easier.[/li]
[li]yes i used cursor, *sql* INTO CURSOR temp[/li]
i was simply gathering information of what are the errors i need to expect when applying so it will run smoothly in applying it rather than apply it then debug
so all in all theres no more problems with the rest stated? just the pathing issue
sorry for giving you a hard time -,-
Dexter
[li]....so i didnt catch up to the "pathing thingy" i just used "USE TBL_TBLNAME" should i still put c:\path\path\tbl_tblname.dbf? [/li]
[li]i agree with the lack of understanding. im something like a student learning vfp. i used both buffering and sql-update, buffering so i can browse over the records with first, next, prev, last. sql-update for adding records coz its easier.[/li]
[li]yes i used cursor, *sql* INTO CURSOR temp[/li]
i was simply gathering information of what are the errors i need to expect when applying so it will run smoothly in applying it rather than apply it then debug
so all in all theres no more problems with the rest stated? just the pathing issue
sorry for giving you a hard time -,-
Dexter
im something like a student learning vfp
Is this a Student Project or not?
If it is I might remind you that the Posting Guidelines state:
Promoting, selling, recruiting and student posting
are not allowed on Tek-Tips Forums.
Good Luck,
JRB-Bldr
Is this a Student Project or not?
If it is I might remind you that the Posting Guidelines state:
Promoting, selling, recruiting and student posting
are not allowed on Tek-Tips Forums.
Good Luck,
JRB-Bldr
Olaf Doschke
Programmer
JRB-Bldr is right about the terms of Tek-Tips. Nevertheless, if you use free tables via USE tablename, you have to CD into the directory, you always will have one command, which sets a path, be it CD <somepath> or at least SET PATH TO <somapath> [ADDITIONAL], so a USE will find the table. Or do you think your EXE will search your whole harddrive? Sure thing is USE sometable.dbf can work, if the sometable.dbf file is either in the current directory or in any path you sepcify with SET PATH. This is nothing new, that's all been said anyway.
Bye, Olaf.
Bye, Olaf.
- Thread starter
- #13
Olaf Doschke
Programmer
I just once saw how android programing works. As far as I know an app is it's own instance of a Dalek Java VM and apps are essentially each in their own environment. This way you can easily forget this is not the case everywhere. It's no a natural fact a programming language has the concept of knowing where all it's files are, especially external files like DBFs are to a foxpro app or DOCs are to Word. But also word will open a doc once you pick it, by using the full path.
The concept of a current directory is not a natural concept of any programming language. If you FOPEN a file in other languages you will not get success with a relative path. It's also a "popular" error to automate Word and open a doc by oWord.Documents.Open("some.doc"), assuming Word will look into the current directory of the foxpro app. This is an internal concept inherited from DOS times, but in windows due to multiprocessing/multithreading this concept is totally inappropriate.
Bye, Olaf.
The concept of a current directory is not a natural concept of any programming language. If you FOPEN a file in other languages you will not get success with a relative path. It's also a "popular" error to automate Word and open a doc by oWord.Documents.Open("some.doc"), assuming Word will look into the current directory of the foxpro app. This is an internal concept inherited from DOS times, but in windows due to multiprocessing/multithreading this concept is totally inappropriate.
Bye, Olaf.
- Thread starter
- #15
mr olaf,
i have stated that i confuse codes not the way or logic in coding. for instance i need to redirect in another activity in android and my hands automatically type DO FORM home(a .java activity) in the same instance to vfp; my hands automatically types initialization of intent. thats what i mean. sorry for the misunderstanding
thanks anyways to the help
Dexter
i have stated that i confuse codes not the way or logic in coding. for instance i need to redirect in another activity in android and my hands automatically type DO FORM home(a .java activity) in the same instance to vfp; my hands automatically types initialization of intent. thats what i mean. sorry for the misunderstanding
thanks anyways to the help
Dexter
Koen Piller
Programmer
Dexterdg,
on top of all the excellent advises you have received on your question I add mine:
donot name the by you made exe System.exe give it a meaningfull name refering to the name of your application.
The change that there is alreade a file on the HD named System.exe is high and why to encrypt?
Regards,
Jockey(2)
on top of all the excellent advises you have received on your question I add mine:
donot name the by you made exe System.exe give it a meaningfull name refering to the name of your application.
The change that there is alreade a file on the HD named System.exe is high and why to encrypt?
Regards,
Jockey(2)
- Status