HXTT foxpro DBF connection

Questions and answers regarding general SQL and backend databases

HXTT foxpro DBF connection

Postby siavash.roozbehan » Tue Feb 09, 2016 6:10 am

Hi Guys,

We have a very serious issue using servoy webclient talking to a foxpro application in the backend via hxtt driver.

The issue is that if I export my solution that is based on our foxpro application table structure with let's say 20 DBF files and put it on a server using a copy of the foxpro application with 21 DBF files (one which did not exist on the other instance of the foxpro application) then try to restart the service, it comes up with an error connecting to the backend database as there are a unknown DBf file in that folder that is not part of the solution!

I don't know why it even tries to look at anything outside of the DBF files associated with the solution? The problem is that that foxpro application keep creating and deleting files on the fly when users are using the application and at any point in time, there might be some extra DBF files in the application folder that are only used by the foxpro application and only that specific user and no one else.

Another issue we have with our servoy solution is that I can't seem to be able to stop the solution import from making database changes on the backend foxpro application. For example, if I try to upload a solution with table 'x' and column 'a' and the foxpro application that the server is pointing to does not have the column 'a' in table 'x', servoy tries to create the column which might be unnecessary. Is there any way that I can import a solution asking it to ignore the database structure? I have tried different options on admin page when trying to upload a new solution but no luck so far.

Your help would be highly appreciated.

Cheers,
Siavash
TSM (The Service MAnager)
Siavash

TSM (The Service Manager)
Australia
siavash.roozbehan
 
Posts: 97
Joined: Wed Apr 11, 2012 2:21 am

Re: HXTT foxpro DBF connection

Postby Bernd.N » Tue Feb 09, 2016 2:51 pm

Hi Siavash,

I regret I can not contribute to the single issues, but a clean approach would be to take the complete solution over to a SQL database like postgres.
I would also investigate if creating and deleting files is really necessary when users use the solution.
I bet you would have much less problems and a much more stable solution in future when you do that. Mixing old and new technology is likely to create problems.
Bernd Korthaus
LinkedIn
Servoy 7.4.9 SC postgreSQL 9.4.11 Windows 10 Pro
User avatar
Bernd.N
 
Posts: 544
Joined: Mon Oct 21, 2013 5:57 pm
Location: Langenhorn, North Friesland, Germany

Re: HXTT foxpro DBF connection

Postby AlanBourke » Tue Feb 09, 2016 3:17 pm

All software creates and deletes temporary files, best practice for the FoxPro application would not be creating DBF files on disk on the fly, it would be creating temporary cursors which may or may not have a disk presence, and if there is a disk presence for these (which Fox will decide automatically based on their size etc) then it should be in a per-user temporary location.
-------------------------------------------------------------------------------------------
Servoy SAN Developer
User avatar
AlanBourke
 
Posts: 198
Joined: Tue Aug 02, 2011 3:32 pm
Location: Dublin, Ireland

Re: HXTT foxpro DBF connection

Postby siavash.roozbehan » Wed Feb 10, 2016 1:06 am

Bernd.N wrote:Hi Siavash,

I regret I can not contribute to the single issues, but a clean approach would be to take the complete solution over to a SQL database like postgres.
I would also investigate if creating and deleting files is really necessary when users use the solution.
I bet you would have much less problems and a much more stable solution in future when you do that. Mixing old and new technology is likely to create problems.



Hi Bernd,

I agree that it would be much easier to manage things if the backend database was on a SQL database like postgres. We currently have a smartclient solution built on top of a postgres database and no issues. But the peoblem is the Foxpro app we are using in the backend for this specific webclient solution is a huge application and already in production for years, so we need to use it with our webclient solution.

Cheers,
Siavash
Siavash

TSM (The Service Manager)
Australia
siavash.roozbehan
 
Posts: 97
Joined: Wed Apr 11, 2012 2:21 am

Re: HXTT foxpro DBF connection

Postby siavash.roozbehan » Wed Feb 10, 2016 1:15 am

AlanBourke wrote:All software creates and deletes temporary files, best practice for the FoxPro application would not be creating DBF files on disk on the fly, it would be creating temporary cursors which may or may not have a disk presence, and if there is a disk presence for these (which Fox will decide automatically based on their size etc) then it should be in a per-user temporary location.



Hi Alan,

Thanks for your comments. The thing is I can't change the way the foxpro application is designed and is working as mentioned earlier, it a a software in production used by hundreds of customers for years now (And it's not my product to modify it too :) )

My problem is that why servoy import solution has to manipulate the database every time it want to import a solution. I simply should have a choice of opting to let servoy handling the database changes for me or not.

And another thing that I do not understand is, why does it have to look through the whole folder for all available DBF files even if they are completely irrelevant to the servoy solution and have never been or will be part of the solution. I would understand if it needs to check for a job.dbf file when trying to access the foxpro application as the solution is using the job.dbf, but for a table zz102.dbf that is a temp file and is totally irrelevant to the solution, it should simply ignore it!
Siavash

TSM (The Service Manager)
Australia
siavash.roozbehan
 
Posts: 97
Joined: Wed Apr 11, 2012 2:21 am

Re: HXTT foxpro DBF connection

Postby Bernd.N » Wed Feb 10, 2016 2:19 am

I guess Servoy is designed by assuming it should have full control over the current database, and therefore it puts its attention to every table in the database, and to every field in each table. This behaviour is the same when using foxpro, which is straightforward as Servoy is database agnostic. The special case that you want to work on just a part of the tables from outside another main solution was probably not considered by design.
Bernd Korthaus
LinkedIn
Servoy 7.4.9 SC postgreSQL 9.4.11 Windows 10 Pro
User avatar
Bernd.N
 
Posts: 544
Joined: Mon Oct 21, 2013 5:57 pm
Location: Langenhorn, North Friesland, Germany


Return to SQL Databases

Who is online

Users browsing this forum: No registered users and 6 guests