Sorry, we found 0 results. Please try another query.
Showing max 10 of results

SPSync v0.8

SPSync is now available in version 0.8. It has a bunch of bug fixes and a better tested sync engine.
Also it is tested on Windows 7 and Windows 8 against SharePoint 2010 and SharePoint 2013.

With Office 2013 you get SkyDrive Pro for free which is the Microsoft tool to sync a local folder with a SharePoint document library. However, this tool has some disadvantages:

  • Obviously, you need Office 2013. SkyDrive Pro cannot be downloaded independently.* You can define only one root folder, where all of your document libraries will show up. With SPSync you can sync any folder you like.* With SkyDrivePro you have no control what happens with conflicts. In SPSync you can define whether you would like to see a conflict dialog, always overwrite local changes or always overwrite remote changes.

SPSync now has a new installer and is no longer a "ClickOnce" application. It does not require administrator rights.

**Download here: **http://spsync.net

To provide feedback use support (at) spsync(dot)net or the FEEDBACK button on http://spsync.net

Access Services 2010: There was an error modifying list schemas

I have an Access 2010 database published to SharePoint 2010. It is a large database, but it is working fine… as far as Access can be fine. I made a lot of changes and added some more columns to one of the tables. I published the database again and everything worked ok.

To make a backup, I saved the database as a local database. Now if I try to publish the same local database to another site in SharePoint I get the following error message:

There was an error modifying list schemas. Failed to rename the field ‘ID’ on the SharePoint list ‘xxx’

Even though the compatibility checker said everything is ok.

Bing doesn’t seem to find a solution, so I tried Fiddler (by the way: great new website) to test what exactly is going on during the publishing process.
And here we have the detailed error message (click to enlarge):

AccessBlog

So what exactly is "_OldID2" and why is there a column I cannot see within the Access Client? And why are there too many columns of some type?

I tried to hide all columns, but modifying the view on the list does not seem to have something to do with it. Then I switched the columns back on and see one column which is not my column and I’ve never seen it before: "_OldID" Wow, why is Access/SharePoint complaining about _OldID2, but all I can see is "_OldID"?

The Solution

Well, it’s really simple: Unhide and then delete the "_OldID" column. That fixed it and it can now be published again. Thank you Access for being such a great tool… not.

SharePoint 2013: SkyDrive Pro couldn't sync this library

On SharePoint 2013 I have a basic document library with enterprise keywords enabled and one additional "People or Group" column set to "People only" (not as a multi value field).

Now I try to sync the library with SkyDrive Pro. It fails with the following error message:

image

The message details:

The query cannot be completed because the number of lookup columns it contains exceeds the lookup column threshold enforced by the administrator. Error code=0x80070093; Error source=Groove

Ok, if you count the enterprise keywords and the people field as lookup fields I have 2. The default "List View Lookup Threshold" (Central Admin –> Web Application –> Resource Throttling) is 8.

Then I tried to set the value to 16. Bam! Now everything is working again. I have no idea why and how 8 shouldn’t be enough with my 2 additional columns (which are of course not even lookup columns).

One in a million is next tuesday – Oder: Warum Backups so wichtig sind

Das Zitat kommt irgendwo von The Daily WTF. Aber von vorne. In der Nacht vom letzten Freitag auf letzten Samstag ist in meinem Server eine der beiden Platten ausgefallen. Da die beiden Platten im RAID-1 Verbund laufen, eigentlich kein Problem. Samstag Mittag also den (sehr schnellen) Support kontaktiert mit der Bitte um Tausch der Platten.

Da begann das Problem. Während des Austausch ist dem Support aufgefallen, dass auch die zweite Platte als defekt gemeldet wird (=> ich weiß, ich sollte wissen, ein RAID-1 ist kein Backup…). Da fing langsam Panik an.

Zunächst wurde also die erste Platte getauscht. Anschließend habe ich dann einen Rebuild des RAIDs versucht, was jedoch fehlschlug. Über das Linux Recovery System und dem wirklich **sehr **zu empfehlenden Tool Testdisk konnte man zumindest die Platte noch ansprechen und auch die Partitionen schienen intakt.

Also zunächst vom Support die zweite Platte einbauen lassen, und die eine defekte Platte als dritte angeschlossen lassen. Dann habe ich erstmal wieder Windows installiert und dann in Windows über Testdisk die Partionen der defekten Platte wieder hergestellt. Es gab zwei VHDX Dateien die leider nicht lesbar waren und somit verloren.

Hier kommt nun das Backup ins Spiel. Selbstverständlich habe ich von allen wichtigen Dateien Backups. Backups sind aber nie das Problem… erst beim Wiederherstellen merkt man die Probleme. Glücklicherweise waren die zwei VMs über ein 1 Monate altes Backup wiederherstellbar und auch sonst ist wieder alles beim Alten.

Learning aus dieser Aktion: Backup besser planen und vor allem besser testen, ob auch wirklich alle notwendigen Daten gesichert und wiederhergestellt werden können.

Empfehlen kann ich definitiv CrashPlan. Denn auch wenn man das Online Backup nicht nutzt, bietet CrashPlan die Möglichkeit, ein Backup auf andere Rechner zu machen (Freunde, Familie, andere Rechner, etc.). Damit sollte sich ein sehr einfaches und dennoch sehr mächtiges Backup Szenario erstellen lassen. Und man kann sicher sein, dass die wichtigen Daten, gesammelt über Jahre, nicht verloren gehen.