2012 server

[dtussman]

I have encountered problems running an xharbour application on 2012 servers. Data is not being saved reliably. Switching to 2008 server resolves the problem. I am using a ten year old version of xharbour. Will upgrading fix this or is there some other fix I should be aware of? Not doing anything fancy, using regular dbf files with ntx indexes.

[Antonio Linares]

Yes, you should use a more recent version and try it again:

https://bitbucket.org/fivetech/harbour-xharbour-builds/downloads/xharbour10121_20150503_bcc58.zip

Surely you will need to upgrade FWH too.

[driessen]

Since Windows 2008 server, I noticed the same problems now and then. But it also happens with recent versions of xHarbour or Harbour.

What is the problem : it is a well known problem by Microsoft that SMB 2.0 (Server Message Block) which was introduced in Windows 2008 server, is making index-files of different types of databases corrupt. It usually happens on a network where a Windows 2008 server (or later versions) is combined with Windows 7 or Windows 8(.1).

If SMB 2.0 was disabled, the problem disappears.

For disabling SMB 2.0, an intervention is needed on the server, as well as on the workstations.

More about disabling and enabling SMB 2.0, you can find more information on : https://support.microsoft.com/en-us/kb/ ... wsignin1.0

[cnavarro]

Michel, thanks

[Antonio Linares]

Michel,

Great info, thanks!

[dtussman]

Thanks Michel, I had heard about this smb2 solution before and was hoping there was a way around it other than disabling, but apparently not. This seems like very bad news as it would imply that harbor applications can no longer be run reliably on any server of recent vintage without disabling smb2, which Microsoft doesn't recommend and is quite an inconvenience, especially when you have over 1200 installations as I do. Am I missing something? Thanks again!

David

[Rick Lipkin]

David

I decided several years ago to migrate all my .dbf's to either Ms Access (.mdb) or MS Sql Server using Ado. All opportunistic locking issues, SMB problems and network slowness Immediately Stopped, Vanished.

To Me it was simpler to migrate my back end to SQL than to have to deal with over 3k desktops in a Government Environment, and I can assure you, The IT people in charge of dealing with Desktop Support would have 'run me out of town' if I had to ask them to 'dink' with their desktops or 'tweak' their network servers.

Probably not the answer you wanted to hear, but Ms Access is FREE and there is a FREE version of Ms Sql server as well and the database code stays the same .. only the connection string to the databases changes.

I know it will take time, but the results make for a more secure back end and all the locking and performance problems just go away.

Was a 'no brainer' for me

Rick Lipkin

ps .. no connection client or elaborate setup is needed .. Windows has it all built in if you use Access or Sql Server

[driessen]

Rick,

Very interesting information I can read from you.

I want to migrate my dbf-files to SQL too.

But can you advice me how I need to do that? I have no experience with SQL right now.

Thanks.

[dtussman]

Rick,

I will second Michel's comment and am wondering also what would be the best way for me to go about following the route you suggest. Are you available as a consultant to help with this or can you recommend another resource? My application is 30 years old (began in dbaseII) and has been modified almost daily since then so as you can imagine its a monster plus I am not a trained programmer so the code is not exactly textbook, but it all works.

Regards,

David

[hua]

Rick,
Isn't MS Access is also a flat file database like dbf and as such will be affected by oplocks issue?

1. Quote - "However this protocol imposes a couple of problems for Xbase++/Clipper and even MS Access or Excel applications running in a shared network environment."

2. http://www.granite.ab.ca/access/corrupt ... plocks.htm

Thank you for sharing your experience

[AHF]

Adordd its ready and it will be publish today.
Ill post the link here later.

It has been in development since Feb 2015 and being tested on real "old" application working in parallel with the actual application with ADS and passed all trials.
This app with adordd its now being tested intensively on concurrent access to check locking scheme and exclusive use. Will report results end next week.

Lucas DeBeltran helped a lot with his trials on his app and with his ideas.
Antonio Linares and Rao Nages help a lot sharing the code of adofuncs.prg and their expertise of rdds and ado.

With adordd you can migrate immediately to any SQL server although all the trials have been made only with ADS, MySql and MS Access.

No change code required. Except:

1) As with ADS in index expressions you have to evaluate vars before send it to adordd.

2) Deleted records are immediately removed from table and cant be recovered again. So code like:

Code: Select all  Expand view

Delete record recno
BlankRec()  //this will not work either comment it or place it before delete.

delete all  //this will not work take it from here
while....
 if lcondition  //change condition to not
   recall record  //delete each record here
 endif
end
 

Thats it!

And goes beyond others rdd:

Code: Select all  Expand view

hb_GetAdoConnection():Execute("CREATE VIEW cView ....")

sele 0
use cView

Browse()
 

True locks as any other rdd.
Upload tables to any Sql server just like:

Code: Select all  Expand view

use table VIA "DBFCDX"
copy to sqltable via "ADORDD"
use sql table
Browse()
 

Performance its quite good.
No Sql knowledge. This will be only needed if you want to use and run sql statements directly from ado functions.
You write code exactly the same as for any other rdd.

With adordd we are free from all this kind of limitations with tables and index management already in actual and future operating systems and will extend the life of our applications further.

Although ADO its already today an "old" framework I think it will stay around for the next coming years (I hope so)

Ill give support to it as long as you can supply precise ideas and sample code where something has not been foreseen in adordd scope of action.

I hope that it will do the job for you all as it does for me.

Ps. Dont go for MSAccess go directly to any SQL server.

[Otto]

Go the best and most secure way – go RDP.
Otto

http://otto-atzwanger-gmbh.com/page-12

[Rick Lipkin]

To All

There is no correct answer, only choices and how you chose to implement those choices has to be weighed out in time and effort on your part and the IT landscape of your client.

viewtopic.php?f=3&t=30888

As far as Ms Access .. .mdb is basically a scaled down ( single portable file ) version of Ms Sql Server. .Mdb is primarily connected via 32 bit Ms Jet 4.0 and that has no problem running in a 32 or 64 bit Windows environment. HOWEVER, if you decide to compile your .EXE with 64 bit, you will need to ALSO setup the MS ACE OleDb ( client ) provider .. see link

http://stackoverflow.com/questions/1440 ... -ace-oledb

Rick Lipkin

[Otto]

>There is no correct answer

Rick, in this case you are wrong.

dtussman has the problem because of mixed operating systems.
To work through RDP is the best way. Your program is running on a single OP system – in his case on the SERVER 2012.
Also a client server system can’t reach the stability of a system on a dedicated machine.

Note
------
Here the only thing to know is that licensing of the CALs in WINDOWS Server 2012 foundation only works in “per device” mode.

Best regards,
Otto

[dtussman]

Otto,

If I understand you you are advocating running my application on a terminal server and accessing through RDP. I already do this with several of my customers and it works great. I imagine it would be a huge job to migrate my application to sql regardless of what anyone says and I may not live that long anyway so the terminal server solution is very appealing. Would you agree? The customers like it because they think they are in the cloud, and you can run the application from anywhere including on Macs without having to mess with Parallels.

David