I have a TRemoteDatamodule (DOA 4.0.7, Delphi 2007) where there are three datasets set in master->detail->detailofdetail relationship. A provider is attached to the master dataset, and details are handled the Datasnap way, embedded as TDatasetFields within the datapacket.
When Unidirectional is set to True to save datasnap server memory, a "Record x not accessible in Unidirectional mode" exception is raised. Looking at the stack trace, it looks detail datasets are refreshed in a way that ends up to call TDataset.First after records are read - and of course that's not possible when the dataset is in Unidirectional mode.
I also see that TDataset.SetUnidirectional() is never called - and it's the method that sets the TDataset.IsUnidirectional property which is checked inside TDataset methods to change TDataset behaviour.
I tried to call it in TOracleDataset.SetUnidirectional(), but that just leads to AVs, probably because with that setting some internal data are not initialized.
Right now the only acceptable workaround I found was to set the master Unidirectional property to True, leaving it to false in details datasets.

UniDirectional can only be used if you can control navigation. It seems that this is not the case here.

AFAIK Unidirectional was introduced by CodeGear to avoid to cache data twice, one on the "source" dataset and one on the "user" dataset, usually TClientDataset, or when cahcing data was useless - dbExpress works that way because TClientDataset caches data.
Because Datasnap can work in a "stateless" mode, it's useless to cache data on the server. It is true that when in M/D mode the detail dataset usually cache a smaller subset of data, but it also true that dataset can't be all set to unidirectional. I don't control navigation, but navigation should happen only forward, because Datasnap should read record that way to build datapackets and send them to che client.