Havi Archívum: November 2007

MOHA azt mondja nekem az én-m oszlop név fenntartva, vagy a használat … De ez nem

Válaszolj

FRISSÍTÉS 12/04/07: Lásd: a Microsoft KB (http://support.microsoft.com/kb/923589) a kapcsolódó információkat.

Valójában, kiderül, hogy az, de takaros MOSS volt, hogy nehéz.

Az én-m ügyfél működik néhány fejlesztési ő MOSS helyén a hétvégén. Egy kicsit egy rakás, hogy ő valójában nem, de a vég eredmény ez:

  • Ő megpróbálja úgynevezett "mennyiség webhelyoszlop hozzáadása" és moha: "A megadott oszlop nevét már van használatban, vagy fenntartott. Válasszon egy másik nevet."
  • Ő megpróbálja hozzáadni egy másik környezet, és hogy működik. Ezért, "Mennyiség" a nem fenntartott nevet.
  • Megpróbálja megtalálni egy meglévő webhelyoszlop nevű "mennyiség" e a webhelycsoportban. Nem találom.

Tettem néhány kutatási, és még néhány kódolási, viaszolt filozófiai és végül megállapította, hogy a nevezett mennyiség oszlop nem, valójában, létezik. Ez volt a "_Hidden" Csoport. Ezért, nem tudtuk megtalálni azt a SharePoint felhasználói interfészen keresztül.

Hogyan tett ez kap ott? nem tudom, van egy elmélet, de (vagy mint a feleségem nevezném, "bla-bla-bla"). Valahol a vonal mentén, egy mesés negyven sablon volt hozzá, és valószínűleg aktivált a webhelycsoport egy helyen. Majd inaktiválva (vagy a helyszínen el). A webhelyoszlop, azonban, de itt a "_Hidden maradt" Csoport. Ha valaki jobban tudja, Kérem, tudassa velem keresztül e-mailben vagy felad-ban magyarázat.

SharePoint volt az igazat. Aligha érdemes rámutatni, hogy ez az üzenet nincs-e, segítőkész, ahogy lehet. Lenne szép-hoz lát a üzenet elágazó a két különböző üzeneteket a jövőben: 1) Azt mondják, hogy az oszlop neve van fenntartva, vagy nem. 2) Ha nem áll fenn, Mutassuk meg a helyszínen, vagy legalábbis a csoport, Ha az oszlop neve már használatban van.

</vége>

Jelen OM adat keresztül egyéni lista (vagy, Még egy másik OM adatok Displayor [mint a YACC, de más])

Válaszolj

Ma, Töltöttem egy maroknyi órát nyomkövető le a gyökér oka mögött a üzenet "a megadott oszlop neve már használatban van vagy fenntartott. Válasszon egy másik nevet."

Az adott oszlop sikerült létrehozni, törlésének és újra létrehozásának egy másik környezetben, így tudtam, hogy nem volt a fenntartott nevet. Azonban, Egyszerűen nem találtam sehol az oszlop keresztül a szabványos SharePoint felhasználói felület bármely helyen a webhelycsoport.

Én kifüggesztett MSDN fórumok itt és a fékezhetetlen Andrew Woodward mutatott nekem irányába az objektum modell alapjául szolgáló adatok.

Elment, hogy Codeplex találni néhány eszközt, hogy segítsen az OM alapadat szakértői, és segítsen nekem megtalálni a baj.

Próbáltam több eszközt, és voltak nagyon jó és érdekes, de a végén, a felhasználói felület nem volt elég jó, a célom. Nem vagyok kritizálta őket bármilyen módon, de egyértelműen az eszköz döntéshozók nem volt problémám szem előtt tartva a felhasználói felület létrehozásakor :). A legtöbb ember úgy tűnik, hogy lehet befektetni egy tisztességes mennyiségű időt és erőfeszítést létrehozásának munkaállomás / kliens alkalmazások, amelyek a fa views, jobb-kettyenés szövegkörnyezet étlap és így tovább. Ezek a szép és minden, de egy csomó munka, hogy hozzon létre egy top-of-the-line felhasználói élmény, ez is nagyon rugalmas.

Én igazán szükséges választ erre a problémára. Eszembe jutott, hogy ha én tudna kap minden a webhelyoszlopok a webhelycsoport egyéni listába, Én tudna szűrő, rendezheti és nézetek, hogy segítsen megtalálni az állítólag létező oszlop létrehozása (hogy, BTW). Mentem előre, és tettem, és egy-két órát, később, volt a webhelyoszlopok töltődik be egy egyéni listát, és a csoportosítás, válogatás és így tovább. Én alapít a válaszom öt perccel később.

Ha sikeresen átveszi a világ, Azt hiszem, lesz rendelet, hogy minden SharePoint eszközök szolgáltatók kell komolyan fontolóra felszínre objektum modell adataikat az egyéni lista. Így, Nekem van a hatalom Keresés bármely módon szeretnék (a korlátozott, természetesen, a szabványos sharepoint-szolgáltatások).

A SharePoint Designer egyéni munkafolyamat-művelet — A megfigyelés <FieldBind tervező típus =”A StringBuilder” … />

1 Válasz

Csak egy gyors megfigyelése, hogy van egy nagyon fontos különbség között ez a kettő meghatározás:

<FieldBind mező = "InParam1" DesignerType = "a StringBuilder" Id = "2" Text = "Bemeneti paraméter #1" />

versus:

<FieldBind mező = "InParam1" Id = "2" Text = "Bemeneti paraméter #1" />

Az első azt mutatja, mint ez az SPD:

kép

míg az utóbbi mutat, mint ez:

kép

I’m not sure how helpful these screen shots are but I put in the effort to make them so you have to view them 🙂

A megfigyelés ez: A StringBuilder lehetővé teszi, hogy építsenek egy karakterlánc (nyilvánvalóan) összekeverésével karakterlánc literálok és munkafolyamat-adatok (keresztül az "Add keresés" gomb a bal alsó sarokban). A keresés hozzáadása gomb használatakor, beszúrja egy jelképes formában"[%token %]". Amikor SharePoint meghívja az egyéni művelet, (C# kód az én esetemben), SharePoint átadja magát a token, a jogkivonat értéke nem. Ha az alapértelmezett tervező típus (a második típus), SharePoint a token kitágul, és átadja a tényleges értékének a token a fellépés.

A StringBuilder = rossz, alapértelmezett tervező típus = jó.

természetesen, Ez nem igazán értem. Csak ne próbáld, és egy paraméter át az egyéni művelet, amikor a tervező típus = StringBuilder. Használja az alapértelmezett tervező típus és a lánc egy StringBuilder rá elöl, ha be kell építeni az összetett kifejezéseket a munkafolyamat (ami egyébként pontosan mit jelent hogy hozzon létre egy dinamikus témát az e-mail akció, de ez a téma egy másik blog bejegyzést, Har har).

<vége />

Korai munkafolyamat-aktiválás — A nem orvosi megoldás

8 Válaszok

FRISSÍTÉS: Lásd az MSDN-vita, különösen az utolsó bejegyzés: http://forums.microsoft.com/MSDN/showpost.aspx?postid=2631057&siteid=1. Leírja a feltétellel, hogy lehet rövid áramkör ezt az egészet. Rövid, lehet, hogy olyan egyszerű, mint, hogy legalább az egyik mező kötelező.

Nekem van egy dokumentumtárban, amely támogatja a nyolc tartalomtípusok.

Nekem van egy SharePoint Designer munkafolyamatot, amely azt akarja, hogy kiszámítja, és rendelje hozzá a "emlékeztető dátuma" egyszerűen kivonásával 30 napon, egy másik oszlop, "esedékesség". Ez csak történjen, az egyik a tartalomtípusok, "Biztosítás". Üzleti célja, hogy készítsen egy KPI-t, ami mutatja a két kategória biztosítási dokumentumok: "körülbelül-hoz kilehel" és a "lejárt." (Tudod olvas több körülbelül ez a fajta KPI és több jelentős részletezése itt).

Nekem van beállítva a munkafolyamat a tüzet, amikor egy új elem jön létre, és amikor egy elem módosítása. Az ötlet az, hogy ha egy biztosítási dokumentumot feltöltött, számítjuk ki a "figyelmeztetés dátuma" a lejárati dátum alapján. Egy pár nézetek munka egy KPI-listát, hogy ezek a feltételek esetén a felhasználók hit a hazai oldalon.

Ez a stratégia nem működik, amikor feltölteni egy dokumentum.

Feltölteni a dokumentumot, és én vagyok bemutatott-val a meta adat belépés képernyő. Ezen a ponton, Én már a baj. SharePoint már, idő előtt a saját szemszögéből, lőttek a munkafolyamat. Nem volt egy esélyt, hogy válassza ki a megfelelő tartalomtípus nem ruház a kellő időpontban. Ezzel egy időben, a munkafolyamat nem tűz, mikor én megüt a alávet gomb, ebben az időben. Van néhány épít--ban logika, hogy "úgy véli" hogy először a küldési része a "létrehozása" esemény. Így … az én munkafolyamat van rúgva, és mikor végre, nem fogadtak el alapértékeket meta adatok.

A legjobb munka-körül tudom, hogy be egy "pause-ig" a munkafolyamat-tevékenység. Már a munkafolyamat szünet, a 1 perc. Míg ez a felfüggesztés, A megfelelő tartalomtípus kijelölése, írja be a meta-adatok. A szünet befejeződik, és a munkafolyamat bevétel szükség szerint. (Vegye figyelembe, hogy a környezetemben, a biztonsági házirendek Adatbázisából időzítő munkafolyamat-tevékenységek nem működnek a dobozból. Előfordulhat, hogy ugyanaz a baj. Lásd: itt További részletekért).

Nem szeretem a "magic késedelem" dolgozik-körül. Mi történik, ha a felhasználó feltölt egy dokumentum és a telefon cseng, és az azt követő beszélgetés outlasts a szünet? Lehet, hogy hosszabb szünet, de még mindig nem tetszik.

Írtam erről a MSDN fórumok itt: http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=2430725&SiteID=1

SharePoint biztonsági alapjainak Primer / Elkerüljék a buktatókat, közös

8 Válaszok

FRISSÍTÉS 12/18/07: Lásd Paul Liebrand cikk néhány technikai következmények, eltávolítására vagy módosítására az alapértelmezett csoport neve (látom a megjegyzést alább is).

– Áttekintés:

SharePoint biztonsági könnyű beállítani, és kezelését. Azonban, Ez bebizonyította, hogy nehéz, hogy tényleg csavarja a kezek körül néhány először rendszergazdáknak. Nem csak, hogy, Nekem van látott némely ügyintéző, a tökéletes megértés, hétfőn, hogy csak elveszett, a péntek, mert nem kell tennie minden olyan konfiguráció, a közbeeső időben jönni. (Bevallom, hogy miután ezt a problémát magam). Ez a blog bejegyzés remélhetőleg biztosít egy hasznos SharePoint biztonsági primer, és néhány biztonsági konfigurációs gyakorlati felé mutat.

Fontos Megjegyzés::

Ez a leírás alapján a dobozból SharePoint biztonsági. Az én személyes tapasztalatom ezen a környéken: MOSS orientált, így lehet, hogy néhány MOSS konkrét dolgot itt, de azt hiszem, ez a WSS pontos. Remélem, hogy bárki látta az előforduló hibákat vagy mulasztásokat akarat pont amit ki-hozzászólások vagy elektronikus levél én. Majd, hogy a javítások utáni sietség.

Alapjai:

Ez az Áttekintés céljából, vannak négy alapvető eleme a biztonsági: felhasználók/csoportok, biztonságossá tehető objektumok, jogosultsági szintek és öröklés.

Felhasználók és csoportok le a szünet:

  • Egyéni felhasználók: Kihúzták aktív könyvtár vagy közvetlenül a SharePoint alkalmazásban létrehozott.
  • Csoportok: A csatlakoztatott közvetlenül az active Directoryból vagy a létrehozott SharePoint. Csoportok olyan felhasználók gyűjteménye. Csoportok a globális webhelycsoportban. Ők soha nem "kötődnek" egy adott biztonságossá tehető objektumhoz.

Biztonságossá tehető objektumok alkalom, hogy legalább:

  • Oldalak
  • Dokumentumtárak
  • Egyedi tételek listákhoz és dokumentumtárakhoz
  • Mappák
  • Különböző BDC-beállításoknak.

Vannak más biztonságossá tehető objektumok, de megkapod a képet.

A jogosultsági szintek: Egy köteg-ból szemcsés / alacsony szintű hozzáférési jogokat, amelyek magukban foglalják többek között a bejegyzéseket létrehozni/olvasási/törlési listák.

Öröklés: Szervezetek alapértelmezett biztonsági beállításait örökli a tartalmazó objektumot. Sub-oldalakon engedélyt örökli a szülő. Dokumentumtárak örökli a helyszínen. Így tovább és így tovább.

Felhasználók és csoportok kapcsolódnak a biztonságossá tehető objektumokhoz keresztül engedélyszintek és öröklés.

A legfontosabb biztonsági szabályok, megérteni, Ever 🙂 :

  1. Csoportok olyan egyszerűen felhasználók gyűjteménye.
  2. Csoportokat egy webhelycsoporton belül globálisak (i.e. nincs ilyen dolog, mint egy csoport a webhely szinten meghatározott).
  3. Csoport neve ellenére sem, csoportok nem, ezen a helyen és a maguk, van bizonyos szintű biztonság.
  4. Csoportok rendelkeznek biztonsági környezetében egy adott biztonságossá tehető objektumhoz.
  5. Az azonos csoportba a minden objektumtól különböző jogosultsági szinteket rendelheti.
  6. Web alkalmazás-házirendek adu mindez (lásd alább).

Biztonsági rendszergazdák elvesztette a csoportok és felhasználók lista tenger mindig számíthatnak a ezek kezelése, és megérteni a biztonsági konfiguráció axiómái.

Közös buktatók:

  • Csoport neve tévesen azt jelenti, hogy engedély: Kívül a doboz, SharePoint meghatározza a csoportokat, akiknek a neve azt jelenti, hogy egy benne rejlő biztonsági szint. Fontolja meg a csoport "Közreműködő". Egy ismeretlen SharePoint biztonsági jól nézni ezt a nevet, és vállalja, hogy a csoport bármely tagja "hozzájárulhat" minden oldal/lista/könyvtár a portál. Ez igaz lehet, de nem azért, mert a csoport neve előfordul, hogy "közreműködő". Csak ez igaz a dobozból, mert a csoport rendelkezik egy jogosultsági szintet, amely lehetővé teszi számukra, hogy a legfelső szintű webhely tartalom hozzáadása/szerkesztése/törlése. Öröklés útján, a "közreműködők" csoport is minden szub-webhely tartalom hozzáadása/szerkesztése/törlése. Egy "szünet" az öröklési lánc és a változás a szub-webhely olyan jogosultsági szintjét hogy tagjai az úgynevezett "közreműködői" csoport egyáltalán nem járul, de csak olvasni (például). Ez nem lenne jó ötlet, nyilvánvalóan, mivel nagyon zavaró lenne.
  • Hozzárendelés nem webhely szintjén. Könnyen összetéveszthető a felhasználói felület. A Microsoft biztosít egy kényelmes link felhasználók vagy csoportok kezelése révén minden webhely "emberek és csoportok" Link. Könnyű azt hinni, hogy amikor én vagyok a telek "xyzzy" és létre egy csoport emberek xyzzy barátait és csoportok a linkre, hogy én csak teremtett egy csoport, ami csak azért létezik: xyzzy. Nem ez a helyzet. Valójában már létrehozott egy csoportot az egész webhelycsoportban.
  • Csoportok tagságát nem térhet el az oldalon (i.e. ugyanaz mindenhol ott a csoport szolgál): Fontolja meg a csoport tulajdonosa"" és a két telek, "A HR" és "Logisztikai". Célszerű lenne azt gondolni, hogy két külön személy maga ezekről az oldalakról — egy HR-tulajdonos és a logisztikai tulajdonosa. A felhasználói felület megkönnyíti a biztonságot kezelő rendszergazdák ütögesse ebben az esetben a. Ha én nem tudom jobban, Én lehet, hogy belépés a HR oldalon keresztül a személyek és csoportok linkek, Válassza ki a "tulajdonosok" Csoport és én HR tulajdonos hozzáadása a csoporthoz. Egy hónappal később, Logisztikai jön, a vonal. Hozzáférés az emberek és csoportok a logisztikai webhelyről, húzza fel a "tulajdonosok hozzáadása" Csoport. Lásd a HR tulajdonosa ott, és vegye rá, arra gondolt, hogy vagyok eltávolítása neki tulajdonosok logisztikai helyén. valójában, Vagyok őt eltávolítása a globális tulajdonosok csoport. Követő, vidámság.
  • Hibás név csoportoknak adott szerepkörön alapuló: A jóváhagyók"" csoport egy tökéletes példa. Mi is a tagjai a csoport jóváhagyása? Ahol ezek jóváhagyása? Én igazán akar emberek logisztikai osztály képesek HR bizonylatokat jóvá? Természetesen nem. Mindig nevet a szerepét a szervezeten belüli csoportok. Ez csökkenti a kockázatát a csoport van egy megfelelő jogosultsági szint a valamely biztonságos objektumhoz rendelt. Név csoportok tervezett szerepük alapján. A korábbi HR-logisztikai forgatókönyv, Kellett volna létrehozni két új csoportok: HR tulajdonosok"" és "logisztikai tulajdonosok" minden értelmes engedélyszintek és a minimális összeg azoknak a felhasználóknak, hogy ezt a munkát, és.

Egyéb hasznos hivatkozások:

Ha Ön már tette ezt a messze:

Legyen szíves hadd tudja a gondolatait a hozzászólások keresztül vagy elektronikus levél én. Ha tudod, más jó referenciák, legyen szíves csinál ugyanaz!

Technorati Tags:

Gyors és egyszerű: Hozzon létre egy adatnézet kijelző (DVWP)

2 Válaszok

Van egy rengeteg nagy információ a WSS 3.0 Adatnézet kijelző (DVWP) több forrásból az interneten. Azonban, Azt találta, hogy meglepően nehéz tájékozódni, ez az első alapvető lépés a. Itt van egy másik cikk a "gyors és egyszerű" foglalkozni, hogy sorozat.

Kövesse az alábbi lépéseket, hogy hozzon létre egy adatnézet kijelzőkön (DVWP). Ezek alapján egy "közlemények" kijelző, de a legtöbb vonatkozik.

  1. Hirdetmények-kijelző létrehozása és hozzáadása a webhelyhez.
  2. Nyissa meg a webhelyet a SharePoint Designer alkalmazásban.
  3. Nyissa meg a webhely default.aspx.
  4. Jelölje ki a közlemények kijelzőt, és kattintson a jobb gombbal.
  5. A helyi menüből, Válassza a "Konvertálás, XSLT adatnézet".

A SharePoint Designer értesíti Önt, hogy ezen az oldalon már testre van szabva, a webhely-definíció. Ez nem feltétlenül rossz, de fontos következményekkel jár (teljesítmény, frissítés, mások) amelyek túlmutatnak a kis "gyors és egyszerű" bejegyzés. Hogy minél több információt erről a témáról, Ajánlom mindkét könyv itt és a kedvenc internetes keresés.

Győződjön meg arról, hogy helyesen tette:

  1. Zárja be és nyissa meg újra a pókháló legel (véletlenül újra az eredeti "új kijelző hozzáadása" könyvelésének elkerülése érdekében).
  2. Válassza ki a kijelző nyíl lefelé, és válassza a "megosztott kijelző módosítása" a menüből.
  3. Az eszköz panel megnyitása jobb.
  4. Ehhez a panel megváltozott a szokásos beállítások megadása:
kép

“Nem kap a séma listában oszloptulajdonság a SharePoint-listából” — Leírás/dolgozik-körül

4 Válaszok

Ezen a héten, Mi végül átvette a probléma, hogy számoltak be a távoli felhasználó: Amikor megpróbálta Excel lista tartalmának exportálása, a dolgok úgy tűnik, hogy kezdődjön meg a munka, de majd Excel akar pukkanás-megjelöl hiba: "Nem kap a listaséma oszloptulajdonsága a SharePoint-listából". Ő volt futás Hivatal 2003, Windows XP és a kapcsolódás moha.

Kerestem a Internets, és látta, hogy némi spekuláció, de semmi 100% végleges. Ezért, Ez a post.

A probléma: Exportálás excel, hogy tartalmaz egy dátum (dátum = az oszlop adattípusa).

Mi működött számunkra: Konvertálja a dátumot "egysoros szöveg". Majd, Alakítsa vissza dátum.

Amit megfejt ez. Jó volt látni, hogy az átalakítás dolgozott, valójában. Ez volt elég ideges, hogy áttérés a dolgok ily módon fog bukni, de ez nem.

Ezt a hibát egy hatalmas árnyék dobott a dátum adattípusú, az ügyfél szem előtt, így fogunk, amely meghatározza a végleges válaszol-ból Mikroszkóp, és remélhetőleg lesz post és frissíteni a következő rövid idő alatt, a hivatalos válasz- és Gyorsjavítási információk itt.

Egyéb hivatkozások:

http://www.kevincornwell.com/blog/index.php/cannot-get-the-list-schema-column-property-from-the-sharepoint-list/

http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=2383611&SiteID=1

<vége>

Subscribe to my blog.

Technorati Tags: ,

Gyors és egyszerű: Küldjön egy e-beágyazott hivatkozás-SharePoint Designer-munkafolyamat

Válaszolj

Egyszer vagy kétszer hónap, valaki a hozzászólás egy fórum kérdés: "Hogyan foglalhatom bele URL-SharePoint Designer-mailt kattintható hivatkozások?"

További magyarázat nélkül bemutatott: (jól, valójában nincs további magyarázat után a kép):

kép

Becky Isserman nyomon követi a hasznos magyarázatot, hogyan kell beágyazni egy láncszem-hoz cikk, e-mailben: http://www.sharepointblogs.com/mosslover/archive/2007/11/20/addition-to-paul-galvin-s-post-about-sending-an-e-mail-with-hyperlinks-in-spd.aspx

Az új kiadás: SharePoint Designer munkafolyamat Extensions (string manipulációs funkciók)

5 Válaszok

FRISSÍTÉS: Lásd itt a gondolataimat forgalmazását a projekt: http://paulgalvin.spaces.live.com/blog/cns!1CC1EDB3DAA9B8AA!569.entry

Én már elfoglalt az én Codeplex projekt, amely jelenleg összpontosít nyújtó string manipulációs extensions, SharePoint Designer segítségével létrehozott munkafolyamatok.

A részleteket lásd itt:

Kezdőlap projekt: http://www.codeplex.com/spdwfextensions

Kiadás: https://www.codeplex.com/Release/ProjectReleases.aspx?ProjectName=spdwfextensions&ReleaseId=8280

Változat 1.0 a következő új szolgáltatásokkal:

Függvény Leírás (Ha nem ugyanaz, mint a .net függvény)
NUM-bejegyzések() Visszatér a szám "tételek" a karakterlánc egy megadott elválasztó.

Például: NUM-bejegyzéseket egy string "a,b,c" az elválasztó"," = 3.

Bejegyzés() Az n-edik tokent ad vissza a karakterlánc egy megadott elválasztó.
Hossza String.Length
Csere() String.Replace()
Tartalmaz() String.Contains()
Visszatér az "igaz szó" vagy a "hamis" szót.
Substring(Start) String.Substring(Start)
Substring(Start,hossza) String.Substring(Start,hossza)
ToUpper() String.ToUpper()
String.ToLower() String.ToLower()
StartsWith() String.StartsWith()
Visszatér az "igaz szó" vagy a "hamis" szót.
EndsWith() String.EndsWith()
Visszatér az "igaz szó" vagy a "hamis" szót.

A BDC futásidejű hiba magyarázata

2 Válaszok

Én okozott a BDC hiba ezen a héten, hogy nyilvánult meg, a felhasználói felület és az a 12 Méhkas Napló futásidőben.

Első, Ez jelent meg, a felhasználói felület:

Nem találta meg a mezők szúrni az összes azonosítóértéket nevű SpecificFinder metóduspéldány helyes végrehajtásához … Biztosítja a bemeneti paraméterek rendelkeznek TypeDescriptor leírókkal minden egyedhez definiált azonosító.

Itt van egy képernyő szemcsésedik:

clip_image001

Is tudna okoz ez az üzenet jelenik meg a 12 Méhkas Napló a térképen (a szabadalmaztatott high-tech-don't-try-this-at-home segítségével "titokzatos hibák" a módszer):

11/14/2007 09:24:41.27 W3wp.exe (0x080C) 0x0B8C SharePoint Portal Server üzleti adatok 6q4x magas kivétel a BusinessDataWebPart.OnPreRender: System.InvalidOperationException: Az azonosító értéket ”, típusú ”, Érvénytelen. Várható értéket System.String"típusú. a Microsoft.Office.Server.ApplicationRegistry.MetadataModel.Entity.FindSpecific(Objektum[] subIdentifierValues, LobSystemInstance lobSystemInstance) a Microsoft.SharePoint.Portal.WebControls.BdcClientUtil.FindEntity(Szervezet szervezet, Objektum[] userValues, LobSystemInstance lobSystemInstance) a Microsoft.SharePoint.Portal.WebControls.BusinessDataItemBuilder.GetEntityInstance(Nézet desiredView) a Microsoft.SharePoint.Portal.WebControls.BusinessDataDetailsWebPart.GetEntityInstance() a Microsoft.SharePoint.Portal.WebControls.BusinessDataDetailsWebPart.SetDataSourceProperties()

Én keresett körül és alapít néhány vezet a MSDN fórumban, de nem volt elég ahhoz, hogy megértsem, mit csinálok rosszul. Néztem egy élő adás, amelyet Ted Pattison amit az én-m Vállalat van mókus el-egy szerveren, és jött, hogy rájönnek a probléma.

Az én ADF, Vagyok csatlakozik, egy SQL adatbázis látható:

            <Ingatlan név="RdbCommandText" Típus="System.String">
              <![CDATA[
                VÁLASSZA KI A SETID, CARRIER_ID, EFFDT, DESCR, EFF_STATUS, TAXPAYER_ID, NETWORK_ID, FRT_FORWARD_FLG, ALT_NAME1, ALT_NAME2, LANGUAGE_CD,
                      ORSZÁG, CÍM 1, CÍM 2, CÍM 3, ADDRESS4, VÁROS, NUM1, NUM2, HOUSE_TYPE, ADDR_FIELD1, ADDR_FIELD2, ADDR_FIELD3,
                      MEGYE, ÁLLAMI, POSTAI, GEO_CODE, IN_CITY_LIMIT, COUNTRY_CODE, TELEFON, KITERJESZTÉS, FAX, LAST_EXP_CHK_DTTM, FREIGHT_VENDOR,
                      INTERLINK_DLL, TMS_EXCLUDE_FLG a dbo.PS_CARRIER_ID_VW (NOLOCK)
                AHOL
                  (SETID <> "SHARE") és
                  (alsó(CARRIER_ID) >= alsó(@MinId)) és
                  (alsó(CARRIER_ID) <= alsó(@MaxId)) és
                  (alsó(DESCR) Alacsonyabb, mint(@InputDescr))
                ]]>
            </Ingatlan>

Én volt, feltéve hogy SQL DBA személytől, és én vagyok megérteni, hogy egy különleges Nézd készítettek, csak számomra. Egyedi kulcs a CARRIER_ID.

Itt van a hiba én bemutatott:

      <Azonosítók>
        <Azonosítója név="CARRIER_ID" TypeName="System.String" />
        <Azonosítója név="DESCR" TypeName="System.String" /> 
      </Azonosítók>

Valahol a vonal mentén, Sikerült összezavarni magam alatt <Azonosítók> és hozzá DESCR, még akkor is, ha a ' nem valójában azonosítója. Vettem DESCR ki a készlet azonosítók és a gyors! Ez munkás.

Remélem, hogy ez ment valakinek némi gyászot 🙂