BMS-HOSxP Community
HOSxP => HOSxP PCU => ข้อความที่เริ่มโดย: doramon ที่ กุมภาพันธ์ 01, 2009, 15:47:49 PM
-
เนื่องจากปัญหา pk ไม่ตรงกันใน provis กับ 18 แฟ้ม
ทำให้ข้อมูลที่เกิดขึ้นที่หลังไม่สามารถนำเข้าได้หรือนำเข้าได้น้อยใน 18 แฟ้ม
นิยามใน 18 แฟ้ม
เช่น ในแฟ้ม service จะประกอบด้วย pcucode กับ seq เป็น pk
คือ 1 การรับบริการจะได้ seq 1 เบอร์
ตัวอย่าง
18 แฟ้ม(2 pk) provis(3 pk)
pcucode seq date pcucode seq pid date
1 1 2002 1 1 1 2002
1 1 2 2003
1 1 3 2004
1 2 2004 1 2 4 2004
จากตัวอย่างเบื้องต้น จะเห็นได้ว่า ข้อมูลใน provis มี 4 record แต่จะเข้า
18 แฟ้ม เพียง 2 record และช่วงเวลาที่เข้าก็จะยึด record แรกที่เข้าเป็นหลัก
ดังตัวอย่าง ก็จะเห็นได้ว่า ข้อมูลที่เข้าปี 2003 2004 จะไม่สามารถเข้าไปได้
เพราะ pcucode กับ seq ใน provis เป็น 1 กับ 1 ทั้งปี 2002,2003,2004
ทำให้นำเข้า 18 แฟ้มได้ record เดียว ทำให้ข้อมูลส่วนนี้สูญหายไปครับ
-
เพิ่มเติ่มครับ
-อีกส่วนหนึ่งจะเกิดจาก key เป็นค่าว่าง หรือ null
ระบบก็จะไม่นำ record นั้นเข้าให้ครับ
-
seq ที่ส่งจาก hosxp / pcu ไม่ซ้ำกันนะครับ อ.อ๊อด
-
seq ที่ส่งจาก hosxp / pcu ไม่ซ้ำกันนะครับ อ.อ๊อด
ไม่ได้เกียวกับ hosxp_pcu ครับ
มันเกียวกับเดิม สอ ส่ง hcis มีการส่งเลข seq ไปแล้ว
แล้ว hosxp_pcu ส่งไปซ้ำเลขเดิมครับ
โปรแกรม PDN ที่รับข้อมูลมันจะไม่รับเลข pcucode+seq ที่ สอ ส่งมาซ้ำครับ
:)
เดิม HCIS 2004-2007
ใหม่ hosxp_pcu 2008
แล้วเลข มัน ซ้ำกัน
ที่ฐานกลาง
-
??? ??? ??? ??? ???
;D ;D ;D ;D ;D ;D
-
seq ที่ส่งจาก hosxp / pcu ไม่ซ้ำกันนะครับ อ.อ๊อด
ไม่ได้เกียวกับ hosxp_pcu ครับ
มันเกียวกับเดิม สอ ส่ง hcis มีการส่งเลข seq ไปแล้ว
แล้ว hosxp_pcu ส่งไปซ้ำเลขเดิมครับ
โปรแกรม PDN ที่รับข้อมูลมันจะไม่รับเลข pcucode+seq ที่ สอ ส่งมาซ้ำครับ
:)
เดิม HCIS 2004-2007
ใหม่ hosxp_pcu 2008
แล้วเลข มัน ซ้ำกัน
ที่ฐานกลาง
ใช่ครับ เมื่อ วัน ศุกร์ที่ 23/1/52 ไปฟัง สนย.(โปรแกรมเมอร์มาพูดเอง) มาชี้แจงที่จังหวัดก็ อธิบายแบบนี้เช่นกัน ถ้าเป็นแบบนี้เป็นปัญหาแน่ๆ......
-
??? ??? ??? :'(
-
วางแผนกันไว้ว่า จะแก้ปัญหานี้ ตามนี้
อ.อ๊อด แก้ไข seq เดิมใน provisdb ใหม่ ให้ run จาก 1 ไปเรื่อยๆ ย้อนหลังตั้งแต่ที่เริ่มส่งเข้า provisdb (ประมาณ 2003) แยก ตาม pcucode
สำหรับ ข้อมูลใหม่ของเดือน กพ.นี้ อ.อ๊อด เขียน โปรแกรมเล็ก ให้แต่ละสอ.ไป update โดยโปรแกรม จะไปสั่ง update ovst_seq_id ของตาราง serial ให้เป็นเลขที่ไกลๆ หน่อย จะได้ไม่ซ้ำกับใน provisdb อีกต่อไป
อ.MN มีคำแนะนำอื่นมั๊ยครับ
ปัญหาเกิดจากเลข seq ของ HCIS เดิมมีปัญหา ข้อมูลบางสอ.มีเลข seq ถึง 50 ล้านกว่า ???
-
วางแผนกันไว้ว่า จะแก้ปัญหานี้ ตามนี้
อ.อ๊อด แก้ไข seq เดิมใน provisdb ใหม่ ให้ run จาก 1 ไปเรื่อยๆ ย้อนหลังตั้งแต่ที่เริ่มส่งเข้า provisdb (ประมาณ 2003) แยก ตาม pcucode
สำหรับ ข้อมูลใหม่ของเดือน กพ.นี้ อ.อ๊อด เขียน โปรแกรมเล็ก ให้แต่ละสอ.ไป update โดยโปรแกรม จะไปสั่ง update ovst_seq_id ของตาราง serial ให้เป็นเลขที่ไกลๆ หน่อย จะได้ไม่ซ้ำกับใน provisdb อีกต่อไป
อ.MN มีคำแนะนำอื่นมั๊ยครับ
ปัญหาเกิดจากเลข seq ของ HCIS เดิมมีปัญหา ข้อมูลบางสอ.มีเลข seq ถึง 50 ล้านกว่า ???
เดียวเย็นนี้จะส่งตัวแก้ใหม่นะครับ
แนะฝากให้ สอ ทุกแห่ง ส่งข้อมูลย้อนหลัง
ตุลาคม 2551 ถึง มกราคม 2552
ใหม่ทั้งหมด
-
อ.อ๊อด ฝากดู ก่อนจะแก้ไข seq น่าจะเรียงลำดับตาม pcucode --> date_serv ก่อน แล้วค่อยเปลี่ยนให้เรียงตามลำดับ
แล้วตารางอื่น นอกเหนือจาก service ที่มี seq คงต้องแก้ตามไปด้วยให้ครบนะครับ (ยุ่งเหมือนกันนะครับ)
:-\
-
ขอแจมหน่อยนะครับ ;D :D ;D :D อย่างที่ผมใช้อยู่ตอนนี้ ก็ให้ สอ. เขาส่งเป็นส่งเดือนนะครับ อย่างมากก็ให้ส่งจากต้นปีงบ ข้อมูลที่ส่งจาก provis เข้า pdn ก็อยู่ที่ประมาณ 80 - 90 % ขึ้นทุกแฟ้มที่ส่งออกนะครับ (PCU v.3.52.1.30)
-
วันนี้ สนย. มาชี้แจงที่ชัยภูมิ และได้เสนอให้ขยายความกว้างของ seq เพื่อให้สามารถส่งออก seq ด้วย vn ได้ข้อมูลน่าจะไม่ซ้ำและเชื่อมโยงไปยังตารางอื่นๆได้ง่ายขึ้น และขอเคลียร์ข้อมูลปีงบประมาณ 2552 ใหม่ทั้งหมด ไม่ทราบท่านอื่นมีความคิดเห็นยังไงบ้างครับ ;D ;D ;D
-
วันนี้ สนย. มาชี้แจงที่ชัยภูมิ และได้เสนอให้ขยายความกว้างของ seq เพื่อให้สามารถส่งออก seq ด้วย vn ได้ข้อมูลน่าจะไม่ซ้ำและเชื่อมโยงไปยังตารางอื่นๆได้ง่ายขึ้น และขอเคลียร์ข้อมูลปีงบประมาณ 2552 ใหม่ทั้งหมด ไม่ทราบท่านอื่นมีความคิดเห็นยังไงบ้างครับ ;D ;D ;D
ฝากด้วย เป็น VN สบายเลย ;D
-
ขยายความกว้างของ seq เค้าไม่รับปากนะครับ และข้อมูลตั้งแต่ ต.ค. - ธ.ค. 51 เค้าตัดข้อมูไปแล้ว
ผมมีข้อเสนอแนะการ run seq เพื่อไม่ให้ซ้ำโดยใช้ ปีเดือนวันและลำดับของการรับบริการโดยลำดับจะเป็นตัวเลขและอักษรภาษาอังกฤษ 2 หลักตั้งแต่ 01-ZZ น่าจะเพียงพอในการรับบริการแต่ละวัน เช่น 2009010101 - 20090101ZZ ครับ ไม่รู้คิดถูกหรือเปล่าพี่ที่เค้าทำโปรแกรม Fantacy แนะนำมาอีกทีครับที่ชียภูมิเจอปัญหานี้
-
ถ้าต้องการ ปรับข้อมูล ลำดับ Seq_id เพื่อส่งออกใหม่ ก็ง่ายนิดเดียวครับ
1. แก้ไขตาราง serial กำหนดค่าเริ่มต้นของ seq_id ใหม่ ที่ serial.name = 'ovst_seq_id'
2. กำหนดค่า seq_id ใหม่ของทุกคน ด้วยคำสั่ง
update ignore ovst_seq set seq_id = get_serialnumber('ovst_seq_id')
3. ส่งออก 18 แฟ้มใหม่ครับ
หมายเหตุ แต่เดิม seq_id มีความกว้างแค่ 8 หลักครับ จึงใช้ VN ไม่ได้
-
2009010101 - 20090101ZZ คำนวนไม่เก่งครับ ตกลงมี visit ได้มากสุด วันละกี่ visit ครับ ??
seq มีตัวอักษร ??? มันแปลกๆนะครับ แล้วเวลา run เลขต่อไป ใน ovst_seq_id บวกเพิ่มได้ แต่คงแปลกๆอยู่ดี
สนย.ทำไมถึงไม่รับปากเรื่องขยายความกว้างจาก 8 ให้รองรับ VN >:(
-
ถ้าต้องการ ปรับข้อมูล ลำดับ Seq_id เพื่อส่งออกใหม่ ก็ง่ายนิดเดียวครับ
ใช่ครับ
แต่ปัญหามันอยู่ที่ฐานข้อมูลใน PDN ซึ่งมีข้อมูลเดิมจาก HCIS ข้อมูล seq มันมั่วๆ ครับ เป็น ตัวอักษรก็มี เลขมากถึง 20 ล้านก็มี กระโดดข้ามไปข้ามมา ถ้าเราปรับใน HOSxP-PCU แล้ว แต่พอส่งออก มา มี seq ที่ไปตรงกับของเดิม PDN ก็จะไม่นำเข้ามาอีกจาก provisdb ทำให้ สนย.ไม่ได้รับข้อมูลใหม่ที่ส่งจาก PDN
ตอนนี้มีบางสอ.โชคดี เลข seq รันได้ค่อนข้างดี ข้อมูลเข้าสนย.ดีครับ
แต่บางสอ.เลข seq มั่วไป มั่วมา (ใน PDN และ Provisdb เดิมนะครับ ไม่ใช่จาก HOSxP-PCU :D) สอ.กลุ่มนี้มีโอกาสที่เลข seq ไปซ้ำกับข้อมูลเก่ามาก ข้อมูลที่เข้า PDN เลยน้อย ครับ
>:(
-
วันนี้ สนย. มาชี้แจงที่ชัยภูมิ และได้เสนอให้ขยายความกว้างของ seq เพื่อให้สามารถส่งออก seq ด้วย vn ได้ข้อมูลน่าจะไม่ซ้ำและเชื่อมโยงไปยังตารางอื่นๆได้ง่ายขึ้น และขอเคลียร์ข้อมูลปีงบประมาณ 2552 ใหม่ทั้งหมด ไม่ทราบท่านอื่นมีความคิดเห็นยังไงบ้างครับ ;D ;D ;D
เห็นด้วยกับวิธีการนี้ ..ไม่ต้องกังวลเรื่อง seq ใช้ vn แล้วจบ....
-
2009010101 - 20090101ZZ คำนวนไม่เก่งครับ ตกลงมี visit ได้มากสุด วันละกี่ visit ครับ ??
seq มีตัวอักษร ??? มันแปลกๆนะครับ แล้วเวลา run เลขต่อไป ใน ovst_seq_id บวกเพิ่มได้ แต่คงแปลกๆอยู่ดี
สนย.ทำไมถึงไม่รับปากเรื่องขยายความกว้างจาก 8 ให้รองรับ VN >:(
ขอโทษครับคุณหมอ ขอแก้ไขเป็น 09010101 - 090101ZZ ครับมีแค่ 8 หลัก แต่ว่าถามโปรแกรมเมอร์จาก สนย. แล้วแนะนำไม่ควรมีตัวอักษรมาปน ผมว่าใช้วิธี อ.MN เหมาะสุดแล้วครับ
-
ขอโทษครับคุณหมอ ขอแก้ไขเป็น 09010101 - 090101ZZ ครับมีแค่ 8 หลัก แต่ว่าถามโปรแกรมเมอร์จาก สนย. แล้วแนะนำไม่ควรมีตัวอักษรมาปน ผมว่าใช้วิธี อ.MN เหมาะสุดแล้วครับ
เห็นด้วยครับ
-
อ.อ๊อด เสร็จหรือครับ รออยู่เดี๋ยวพรุ่งนี้จะเริ่มใช้ที่อ.ท่ามะกาก่อนครับ :D
-
อ.อ๊อด เสร็จหรือครับ รออยู่เดี๋ยวพรุ่งนี้จะเริ่มใช้ที่อ.ท่ามะกาก่อนครับ :D
กำลังทดสอบครับ
กลัวมีปัญหา
-
กลัวมีปัญหา
;D ;D ;D ;D ;D ;D ;D