FILE_ADD_TO_DB is using the wrong path

[Ronald Anusiewicz]

I have a script that runs when my application starts up. If I install a patch and my app doesn�t match the current patch id, the script runs. A portion of the script checks for the existence of a table. If the table does not exist, my script adds the table and its fields.

The tables that xbasic is creating and adding to the database all have the wrong path. Somehow, alpha is picking a legitimate path with the correct table name, but it�s not the current path of the opened database. Can anyone see anything wrong with this code?

'if the Table 'wk1' is missing from the Database, add it
tblName = "wk1"
tblFields = <<%a%
Env,C,4,0	
wk1,N,15,2	
Date,D,8,0	
Sequence,N,7,0	
Checknum,C,15,0	
Special,C,20,0	
Amount,N,11,2	
Origenvnumber,C,4,0	
Posted_Date,D,8,0	
Arce,L,1,0		
%a%

Check_Table(tblName, tblFields)

FUNCTION Check_Table as L ( tblName as C, tblFields as C )
	
	dim fTbl as P
	'if the table 'tblName' is missing, add it.
	on error goto table_missing
	fTbl = table.open(tblName,file_rw_shared)
	on error goto 0
	fTbl.close()
	goto cleanup
	
	table_missing:
	addtbl=a5.Get_Path()+chr(92)+tblName+".dbf"
	create_table(addtbl,tblfields)
	FILE_ADD_TO_DB(addtbl)
	resume 0
		
	cleanup:
	
	END
	
END FUNCTION

[Stan Mathews]

Re: FILE_ADD_TO_DB is using the wrong path

Your code seems to run fine here. V5, V8, and V10.5 though I did run it all in one script.

[Ronald Anusiewicz]

Re: FILE_ADD_TO_DB is using the wrong path

Hi Stan,

I think I figured out the error of my ways. That said, I�m not sure how to resolve what I�m trying to accomplish.

I have a working application. I develop an improvement which requires the addition of another table. I used xbasic to add the new table. I do this on my developmental application.

Now I want to distribute an upgrade patch to different clients. What I have been doing was to backup my developmental app unmarking the data files only. When the client runs a restore, the new tables have retained the original path of my developmental application. Humm.

I guess I would have to unmark all references to the new tables, but wouldn�t I lose the field rules and forms, browses, etc.??

I�m trying to make this very easy for the client as most are not that computer literate.

Ron

[Ray in Capetown]

Re: FILE_ADD_TO_DB is using the wrong path

Hi Ron

FILE_ADD_TO_DB() must be run on the client side before the version update that delivers it. That can be problematic sometimes.

The solution now is for you to send a new update containing

FILE_DROP_FROM_DB("wk1.dbf") 
FILE_ADD_TO_DB("wk1.dbf")

No explicit paths!. Alpha knows the location of the table to drop, then uses the default path to add.

[CALocklin]

Re: FILE_ADD_TO_DB is using the wrong path

Ron's solution should work but I think there's a much better way....

This is one of the reasons I love my 3rd party installer. I use Astrum but there are probably others that are free and could also handle this situation for you.

This in not exactly what I do but the basics are the same:

I create an install routine that contains everything - data files (includes index and memo files), data dictionaries, sets (really just more data dictionaries), and the adb and al* files. Then - and this is what A5's installer can't do - I set all the data files to "Never Overwrite". Now adding a new table is simple. Before running the install creator program to build the next installer, I simply delete the test records in the new table and add that table to the list of Files to Install in the installer setup dialog (along with all the data dictionaries for that table, of course) and mark it as "Never Overwrite". Now the table will be installed automatically the first time the install is run but never again after that - unless the table is deleted, of course.

This completely eliminates the need to drop and add tables to the db. It also eliminates the need for your Check_Table routine. In fact, if your user deletes a table for some reason and doesn't have a backup, all they need to do is re-run the latest install routine - only the missing tables will be replaced; not the existing tables. The data dictionaries, etc. will also be replaced but so what - they are being replaced with exactly the same files as the last time the customer ran that install.

FWIW:

I also break my install list into multiple "install items" but they are all defined as "Minimum files required for the application to run". The reason for separating them is just for my own sanity when trying to verify what has been included. I break mine into:

Application Files - the .adb and .al* files
Data Files - .dbf, .cdx, and .fpt
Data Dictionaries - .dd*
Sets - .se*
Addins (if I'm including any - typically my backup and/or registration addin)
and usually something like "Misc" or "Support" which is anything else needed.

In addition to making it easier to see what files are included, this also makes it easy to select all the files in the Data Files group and set them to Never Overwrite.

I also found out that the install runs faster if the other groups are set to Always Overwrite. Apparently that eliminates the time required to decide what to do. Even if nothing actually needs to be overwritten, the Always Overwrite was still faster last time I tested it.

[Ray in Capetown]

Re: FILE_ADD_TO_DB is using the wrong path

Cal

"The data dictionaries, etc. will also be replaced but so what - they are being replaced with exactly the same files as the last time the customer ran that install."

Correct me here but isnt that where Ron got the problem in the first place, he creates the file correctly in place but the data dictionaries etc have the location as elsewhere.?
I do think Astrum installer sounds great- i keep saying I must look into it.

[CALocklin]

Re: FILE_ADD_TO_DB is using the wrong path

The problem is that there is no table when the application first opens. The table is created later by the script. Even though the data dictionaries are there, A5 is looking for the table and it isn't there. The "what's on the control panel" issue happens before the script runs.

By putting the table in as part of the initial install, A5 finds it and correctly adds it to the Control Panel. Or perhaps it would be more correct to say that A5 correctly updates the control panel to show the correct path.

Re: I do think Astrum installer sounds great- i keep saying I must look into it.
There is no way I would even consider going back to just using zip files for installations and updates. If I couldn't use Astrum for some reason, I'd be looking for something similar - free would be nice but I'd pay for it if that's what it took to find the features I want. I feel that it saves me lots of time and even more frustration. Sure, it takes awhile to set up an install the first time (and even longer the very first time you use the program) but once an install "definition" has been created, it seldom needs to be changed and future updates are very easy to create - in some cases it's as simple as opening the install creator program and clicking the "create new install" button. (Although I usually at least change the version number and typically update my ReadMe to describe the latest changes.)

[Ronald Anusiewicz]

Re: FILE_ADD_TO_DB is using the wrong path

Thanks,

You've given me something to think about.

Ron