① 在安裝用友ERP U8中的資料庫伺服器名和超級用戶口令該如何設置
一，如果只是在安裝階段，那設置成你自己想要的名字就可以了呢，口令也是隨意設置的，只要密碼位數輸入正確就可以了，一般是四至六位的。
二，其他許可權的設定：
進入系統管理，操作員 admin 密碼空
進入後，許可權下有---用戶和許可權兩個選項
用戶：功能：增加用戶，設置密碼
許可權：給指定的賬套設置操作員（先選賬套再選操作員,點擊修改時單獨指定許可權，打√賬套主管就是全部許可權）。
② 如何優化erp資料庫
數據,也許你現在覺得沒有用,匯總了,將來不知道什麼時候就用到
所以不管什麼優化方式都是不科學的
只能是說,根據你最緊迫的需求進行處理
比如你的ERP系統由於數據過多而緩慢，那麼一是想辦法升級硬體、二是想辦法優化資料庫、三是引用更好的演算法
從優化來說，可以加索引、可以改視圖、可以優化存儲過程，還可以去掉一些目前看無用的數據，而這最後一條往往是見效最快的
所以很多ERP軟體採用的是年結的方法，每年建個新資料庫，速度會有顯著提升
但是，分割的時間段和粒度和企業數據量和規模應該緊密相關
而這么做，損失的是歷史數據，或者說犧牲了歷史數據的分析方便性，而提升了現有數據處理能力
那麼，等你們解決了現有矛盾，需要從歷史數據挖掘信息時，就應該引入數據集市技術，獨立於ERP系統進行數據的切片和分析。
所以，為了將來能夠進行有效分析，我建議你採用的優化手段一定是要改善現有ERP系統處理速度，而同時不損害歷史既有數據的方法。這需要你的軟體供應商能夠支持，或者你作為軟體廠商需要考慮。
③ ERP顯示報表資料庫連接失敗是什麼原因
資料庫連接失敗有很多原因，可能是網路問題也可能是資料庫服務掛了
④ ERP管理軟體資料庫系統的幾種設計方法
1. 自增長primary key採用自增長primary key主要是性能。早期的資料庫系統，經常採用某種編號，比如身份證號碼，公司編號等等作為資料庫表的primary key。然而，很快，大家就發現其中的不利之處。 比如早期的醫院管理系統，用身份證號碼作為病人表的primary key。然而，第一，不是每個人都有身份證；第二，對於國外來的病人，不同國家的病人的證件號碼並不見得沒有重復。因此，用身份證號碼作為病人表的primary key是一個非常糟糕的設計。考慮到沒有醫生或者護士會刻意去記這些號碼，使用自增長primary key是更好的設計。 公司編號採用某種特定的編碼方法，這也是早期的資料庫系統常見的做法。它的缺點也顯而易見：很容易出現像千年蟲的軟體問題，因為當初設計資料庫表的時候設計的位數太短，導致系統使用幾年後不能滿足要求，只有修改程序才能繼續使用。問題在於，任何人設計系統的時候，在預計某某編號多少位可以夠用的時候，都存在預計不準的風險。而採用自增長primary key 則不存在這種問題。同樣的道理，沒有人可以去記這些號碼。 使用自增長primary key另外一個原因是性能問題。略有編程常識的人都知道，數字大小比較比字元串大小比較要快得多。使用自增長primary key可以大大地提高數據查找速度。 2. 避免用復合主鍵 (compound primary key)這主要還是因為性能問題。數據檢索是要用到大量的 primary key 值比較，只比較一個欄位比比較多個欄位快很多。使用單個primary key 從編程的角度也很有好處， sql 語句中 where 條件可以寫更少的代碼，這意味著出錯的機會大大減少。 3. 雙主鍵雙主鍵是指資料庫表有兩個欄位，這兩個欄位獨立成為主鍵，但又同時存在。 資料庫系統的雙主鍵最早用在用戶管理模塊。最早的來源可能是參照操作系統的用戶管理模塊。 操作系統的用戶管理有兩個獨立的主鍵：操作系統自己自動生成的隨機 ID (Linux, windows 的 SID), login id。這兩個 ID 都必須是唯一的，不同的是，刪除用戶 test 然後增加一個用戶 test, SID 不同，login id 相同。採用雙主鍵主要目的是為了防止刪除後增加同樣的 login id 造成的混亂。比如銷售經理 hellen 本機共享文件給總經理 peter, 一年後總經理離開公司，進來一個普通員工 peter ，兩個peter 用同樣的 login id, 如果只用 login id 作操作系統的用戶管理主鍵，則存在漏洞：普通員工 peter 可以訪問原來只有總經理才能看的文件。操作系統自己自動生成的隨機 ID 一般情況下面用戶是看不到的。 雙主鍵現在已經廣泛用在各種資料庫系統中，不限於用戶管理系統。 4. 以固定的資料庫、表應付變化的客戶需求這主要基於以下幾個因素的考慮： ◆4.1 大型EPR系統的正常使用、維護需要軟體廠商及其眾多的合作夥伴共同給客戶提供技術服務，包括大量的二次開發。 如果用戶在軟體正常使用過程中需要增加新的表或者資料庫，將給軟體廠商及其眾多的合作夥伴帶來難題。 ◆4.2 軟體升級的需要。 沒有一個軟體能夠讓客戶使用幾十上百年不用升級的。軟體升級往往涉及資料庫表結構的改變。軟體廠商會做額外的程序將早期版本軟體的資料庫數據升級到新的版本，但是對於用戶使用過程中生成的表進行處理就比較為難。 ◆4.3 軟體開發的需要。 使用固定的資料庫庫表從開發、二次開發來說，更加容易。對於用戶使用過程中生成的表，每次查找數據時都要先查表名，再找數據，比較麻煩。 舉例來說，早期的用友財務軟體用Access作資料庫，每年建立一個新的資料庫。很快，用戶和用友公司都發現，跨年度數據分析很難做。因此這是一個不好的設計。在 ERP 中，很少有不同的年度數據單獨分開。一般來說，所有年份的數據都在同一個表中。對於跨國公司甚至整個集團公司都用同一個 ERP 系統的時候，所有公司的數據都在一起。這樣的好處是數據分析比較容易做。 現在大多數資料庫系統都能做到在常數時間內返回一定量的數據。比如，Oracle 資料庫中，根據 primary key 在 100萬條數據中取 10 條數據，與在1 億條數據中取 10 條數據，時間相差並不多。 5. 避免一次取資料庫大量數據，取大量數據一定要用分頁這基本上是現在很多資料庫系統設計的基本守則。ERP 系統中超過 100萬條數據的表很多，對於很多表中的任何一個，一次取所有的會導致資料庫伺服器長時間處於停滯狀態，並且影響其它在線用戶的系統響應速度。 一般來說，日常操作，在分頁顯示的情況下面，每次取得數據在 1-100 之間，系統響應速度足夠快，客戶端基本沒有特別長的停頓。這是比較理想的設計。這也是大型資料庫系統往往用 ODBC, ADO 等等通用的資料庫聯接組件而不用特定的速度較快的專用資料庫聯接組件的原因。因為系統瓶頸在於資料庫( Database) 方面(數據量大)，而不在於客戶端(客戶端每次只取少量數據)。 在B/S 資料庫系統中，分頁非常普遍。早期的資料庫系統經常有客戶端程序中一次性取大量數據做緩沖。現在已經不是特別需要了，主要原因有： ◆5.1 資料庫本身的緩沖技術大大提高 大部分資料庫都會自動將常用的數據自動放在內存中緩沖，以提高性能。 ◆5.2 資料庫聯接組件的緩沖技術也在提高。 包括ADO 在內的一些資料庫聯接組件都會自動對數據結果集(result set)進行緩沖，並且效果不錯。比較新穎的資料庫聯接組件，比如 Hibernate 也加入了一些數據結果集緩沖功能。 當然，也有一些資料庫聯接組件沒有對數據結果集進行緩沖，比如 JDBC Driver，不過幾年之內情況應該有所改觀。也有些不太成功的數據緩沖，比如 EJB 中的實體Bean，性能就不盡如人意，實體Bean數據也是放在內存中，可能是因為佔用內存過多的緣故。 相對來說，今天的程序員寫客戶端數據緩沖，能夠超過以上兩個緩沖效果的，已經比較難了。
⑤ 通用Excel能跟別的ERP系統或資料庫對接么要怎麼設置
你這個需要二次開發啊
Excel作為數據過度，很容易出問題的
⑥ 易助ERP放在E盤。系統重裝後無法聯機資料庫伺服器，請問要怎麼設置
你的資料庫伺服器是在本機，還是在哪裡。
⑦ ERP資料庫設計
你的要求僅僅是針對美容院總店和分院原料供應的管理嗎？ 如果是，其實可以用很簡單的物流管理ERP做到，但如果要一些針對美容院專屬業務管理，就需要另外做些定製開發。