pkanavos

Και τί γίνεται με όσους έχουν κερδίσει άδειες MSDN ή Technet στα event μας? Από τη στιγμή που δεν υπάρχουν τιμολόγια, την κάτσανε σε ένα έλεγχο? Αν κατάλαβα καλά πάντως, η BSA είναι Yet Another Company η οποία κάνει τα ίδια πράγματα με τους φορείς που Δημοσίου αλλά για λογαριασμό μερικών μόνο εταιρειών. Και προφανώς πρέπει να αποδείξει ότι συμφέρει περισσότερο από τους φορείς του Δημοσίου, αλλιώς θα χάσει τους πελάτες της. Κάτι σαν τα collection agencies, ειδικά αν παίρνει προμήθεια από τα πρόστιμα. Ίσως γι αυτό και η BSA να προσπαθεί να βρει λεφτά από αναπτυξιακά προγράμματα ....

Σε μία εταιρεία πιο πιθανό είναι να χρησιμοποιούν Blackberry ως εταιρικά τηλέφωνα παρά κάτι άλλο (εταιρικά= το δίνουμε σε πολλούς, όχι παίρνουμε ένα για το διευθυντή). Αν όχι τίποτε άλλο, τα Android και τα iPhones δεν έχουν σχεδόν καμμία δυνατότητα management. Είναι κάπως πιο εύκολo o admin να ζητήσει το τηλέφωνο που υποστηρίζει για όλη την εταιρεία. Γι αυτό άλλωστε και η Derdack θα το βγάλει μαζί για WP7 και Blackberry. Το WP7 σίγουρα έχει ένα wow factor (το οποίο ενισχύει το πραγματικό προϊόν, το enterprise alerting server) αλλά το κόστος του και κυρίως, η πολύ μικρή αυτονομία, περιορίζουν πολύ το τί μπορεί να κάνει κανείς. Αν το δούμε πιο σοβαρά πάντως, τα νέα smartphones μπορούν πλέον να υποστηρίξουν άνετα σενάρια alerting πέρα από το κλασσικό SMS. Το χαμηλό κόστος των Android (ξεκινώντας από 100+) σημαίνει ότι μπορείς να δώσεις μία πιο δυνατή συσκευή στον admin η οποία θα μπορεί να λάβει και να εμφανίσει πολύ περισσότερες πληροφορίες από το απλό SMS. Δεν ξέρω κατά πόσο θα αγόραζε κανείς ένα ξεχωριστό προϊόν για mobile alerting, αλλά ένα mobile alert client για το βασικό monitoring σύστημα σίγουρα θα έχει ενδιαφέρον.

Τώρα, το μόνο που μένει είναι να πείσεις τα αφεντικά να αγοράσουν WP7 στον admin! Απ' ότι βλέπω πάντως, όταν βγει η εφαρμογή θα υποστηρίζει και BlackBerry και Windows Phone 7. Μου φαίνεται πολύ πιθανότερο να έχει ο admin BlackBerry (για να μπορεί να υποστηρίζει τους διευθυντές φυσικά).

Το SharePoint Services 3.0 είναι η "μικρή" έκδοση του 2007 με λιγότερες δυνατότητες και features και συνεπώς δεν έχει νόημα το "migration" από 2007 σε 3.0. Το ίδιο ισχύει και για το SharePoint Foundation 2010. Απλά, η ερώτηση δεν έχει νόημα. Αυτό που ζητάς λέγεται downgrade και ... δεν υποστηρίζεται. Ακόμα και αν δοκιμάσεις να κάνεις backup από τη μεγάλη έκδοση και restore στη μικρή θα σου κτυπήσει λέγοντας ότι δεν είναι συμβατές οι εκδόσεις ή οι βάσεις. Είσαι σίγουρος ότι θέλεις να κάνεις downgrade? Αν ήδη έχεις στημένο 2007 γιατί θέλεις να πας σε 3? Ή μήπως θέλεις να κάνεις κάτι διαφορετικό? Μήπως έφτιαξες κάποιο site σε 2007 ενώ το deployment πρέπει να γίνει σε 3? Μία λύση που ίσως να δουλέψει είναι να φτιάξεις ένα template από το 2007, να τη σώσεις στο σκληρό και να την κάνεις import στο 3. Για να δουλέψει αυτό βέβαια πρέπει να μην χρησιμοποιεί το site σου ΚΑΝΕΝΑ feature του 2007 διαφορετικά και αυτό θα αποτύχει.

Αν διαβάσουμε την αρχική πηγή του άρθρου στο ComputerWorld βλέπουμε τα εξής: Υπάρχει νομικό πλαίσιο (Safe Harbor Agreement από το 2000) βάση του οποίου δεδομένα μπορούν να μεταφερθούν από την Ευρώπη στην Αμερική με ασφάλεια. Το πλαίσιο αυτό ακυρώνεται αν οι αμερικανικές αρχές επικαλεστούν το Patriot Act του 2001. Συνεπώς το Safe Harbor agreemement δεν αξίζει ούτε για @@@@χαρτο. Αυτό είναι γνωστό εδώ και ΠΟΛΥ καιρό. Τα καμάρια μας στην Ευρωβουλή και την Ευρωπαϊκή Επιτροπή κάνανε 10 χρόνια να το πάρουν χαμπάρι και παραλίγο να πνιγούν καθώς πίνανε τις βελγικές τους μπύρες. Και η κατάληξη είναι, δε πα να ρωτάνε όσο θέλουν οι ευρωβουλευτές (σιγά μη χυθεί η μπύρα!) κατάσταση που ισχύει 10 χρόνια δεν αλλάζει όχι σε ένα μήνα, αλλά ούτε σε χρόνια. Από την άλλη, κυριολεκτικά, δεν αλλάζει και τίποτε για εμάς. Ό,τι ισχύει 10 χρόνια τώρα εξακολουθεί να ισχύει!

Το version ή το collation δεν παίζουν ρόλο καθώς τα downloads που αναφέρει ο Billytsik είναι διαφορετικά components του CU3. Το τί κάνει το κάθε πακέτο περιγράφεται (όχι με τον καθαρότερο τρόπο) στο Naming Schema for MS SQL Server Update Packages . Από εκεί φαίνεται ότι το SQLServer2008R2 είναι το κυρίως CU, το 2008R2_RTM_RSShrPnt είναι Sharepoint Addin του RS, το SapBI είναι o SAP BI connector , MD_Services τα ... master data services και το SNAC το Native Client connectivity. Ανάλογα με το τί χρησιμοποιείς θα πρέπει να εγκαταστήσεις τα αντίστοιχα πακέτα. Προφανώς το κυρίως πακέτο, αν έχεις Sharepoint το addin, και αν χρειάζεται (δηλ αν έχεις δει κάποιο από τα θέματα που αναφέρονται στο KB) στους client θα πρέπει να βάλεις το SNAC. Επίσης θα κοίταζα να εγκαταστήσω πιο πρόσφατο CU, καθώς τα CU έχουν φτάσει αισίως στο CU 8

Τα βιβλία του Celko αφορούν αποκλειστικά και μόνο προγραμματισμό, και μάλιστα για standard SQL. Δεν ασχολούνται με το administration κάποιου συγκεκριμένου προϊόντος.

Δεν θα το έλεγα. Δεν πρόκειται για κάτι καινούριο, ούτε πρόκειται για κάποια επιβεβαιωμένη φήμη ούτε καν για "παραδοχή" και σίγουρα όχι για "αποκάλυψη". Το ZDNet έχει κάνει ολόκληρη σειρά άρθρων από τον Απρίλιο για το θέμα ενώ στο ZDNet και λένε απλά αυτό που ήδη ξέρουμε. Μία αμερικάνικη εταιρεία υπόκειται στους αμερικάνικους νόμους ακόμα και αν δραστηριοποιείται εκτός Αμερικής. Αν το PATRIOT Act υποχρεώνει το Amazon, το Google ή την Microsoft να αποκαλύψει δεδομένα, αυτό ισχύει τόσο στην Αμερική όσο και στην Ευρώπη. Ο τίτλος του τελευταίου άρθρο στη σειρά μάλιστα τα λέει όλα: USA PATRIOT Act: The myth of a secure European cloud? Αντί να παρασυρόμαστε από εντυπωσιακούς τίτλους καλύτερα να σκεφτούμε σοβαρά τί σημαίνει το cloud, η χρήση ενός ISP ή ακόμα και το outsourcing, τί αξία έχει το απόρρητο (συνήθως πολύ μικρότερη απ' ότι φανταζόμαστε). Ας μην ξεχνάμε ότι όλοι μας σχεδόν χρησιμοποιούμε email χωρίς κρυπτογράφηση, τα περιεχόμενα του οποίου είναι διαθέσιμα τόσο στους administrator τους δικούς μας και των παραληπτών μας, αλλά και των ενδιάμεσων ISP. Κι όμως κανείς σχεδόν δεν χρησιμοποιεί PKI γιατί δεν αξίζει το κόστος. Αν θέλουμε να προστατέψουμε το απόρρητο των δεδομένων που ανεβάζουμε οπουδήποτε υπάρχουν φυσικά λύσεις, με αυξανόμενο κόστος και περιπλοκότητα ανάλογα με το βαθμό προστασίας. Αν έχουμε σκοπό να στήσουμε την κατάλληλη δομή PKI μπορούμε να κρυπτογραφήσουμε τα δεδομένα που ανεβάζουμε με publick key encryption. Από την άλλη, αν κρατάμε τα "βιβλία" κανενός εμπόρου όπλων ή ναρκωτικών, καλό είναι να μην ανεβάσουμε ποτέ τα δεδομένα παραέξω. Όχι τίποτε άλλο, ο πελάτης μπορεί να μην συμφωνήσει ...

Και η Oracle μία έκδοση βάσης SQL είναι. Σε όλες τις βάσεις, o Database Administrator είναι ο ρόλος που αναλαμβάνει να τις προσέχει και να τις ποτίζει. Τα καθήκοντα είναι επίσης παρόμοια, αφού τελικά μία βάση από την άλλη δεν διαφέρει και τόσο πολύ - αν και μερικές βάσεις χρειάζονται περισσότερη φροντίδα από άλλες. Υποψιάζομαι ότι όταν λές "στην SQL" εννοείς τον SQL Server. Η βασικότερη πηγή πληροφορίας είναι το ίδιο το documentation του SQL Server το οποίο καλύπτει με λεπτομέρειες πως να κάνεις backup/restore, attach/detach, να φτιάχνεις χρήστες, jobs κλπ. Το documentation εγκαθίσταται όταν στήνεις και τον SQL Server ενώ μπορείς να το βρεις και online. Νομίζω ότι θα βρεις πιο ενδιαφέροντα το κομμάτι του Operations και ειδικά του Administration. Αυτό δεν σημαίνει ότι ένας administrator δεν ασχολείται με σχεδίαση ή deployment, απλά ότι οι καθημερινές εργασίες ανήκουν περισσότερο σε αυτή την κατηγορία. Σε όλες τις κατηγορίες υπάρχουν και τμήματα How-To όπως το Administration How To τα οποία αποτελούν ένα γρήγορο reference για να κάνεις κάποιες βασικές δουλειές. Υπάρχει επίσης ένα εξαιρετικό βιβλίο, το SQL Server 2008 Administrator's Pocket Consultant το οποίο περιέχει συνοπτικά όσα χρειάζεται να ξέρεις για το administration και έχει κυριολεκτικά μέγεθος τσέπης και μπορείς να το κουβαλάς ακόμα και στην τσέπη του μπουφάν (το έχω κάνει). Αξίζει οπωσδήποτε τα λεφτά του. Μπορείς επίσης να βρεις στο Technet μία παλιά έκδοση για τον SQL Server 2000. Προφανώς, διαφορές υπάρχουν αρκετές σε σχέση με τον SQL Server 2008 αλλά μπορεί να σε βοηθήσει αρκετά σε θέματα backup/restore, user management, job management κλπ. Θα πρέπει να έχεις υπόψη όμως ότι το UI και τα εργαλεία έχουν αλλάξει αρκετά προς το καλύτερο και πολλές εργασίες γίνονται πλέον πολύ ευκολότερα. Από την άλλη, μέσα σε 10 χρόνια έχουν προστεθεί πολλά νέα features που δεν καλύπτονται στην έκδοση του 2000.

Καταρχήν, δεν αναφερόμουν σε εσένα αλλά εννοούσα ότι το ότι κάποιος σου είπε ότι έκανε κάτι, δεν σημαίνει ότι είναι και το σωστό νομικά. Όσον αφορά τις εξουσιοδοτήσεις, εννοούσα ότι οι εξουσιοδοτήσεις των εταιρειών δεν δίνουν κανένα δικαίωμα στην BSA να απαιτήσει υπεύθυνες δηλώσεις. Το ότι έχουν εξουσιοδοτηθεί για ελέγχους είναι εντελώς άλλο πράγμα. Όσο για το να παραδεχθείς κάτι ... σκέψου το εξής: Αν κάποιος γείτονας αρχίσει να σπέρνει στο χωράφι σου και δεν διαμαρτυρηθείς, τί θα γίνει μετά από 10 χρόνια? Μπορεί η BSA να θέλει να γλυτώσει δουλειά, μπορεί όμως και να θέλει να ψαρεύει στα θολά. Καλύτερα να τους κόβει κανείς την όρεξη νωρίς, πριν καταλήξουμε σε καταστάσεις ACS:Law. Εδώ γίνεται φασαρία για ψύλου πήδημα με τις διάφορες Αρχές Προστασίας, και η BSA πάει και ζητάει υπεύθυνες δηλώσεις ? Αν αφήσεις την BSA να ζητήσει τώρα υπεύθυνες δηλώσεις, ποιός σου λέει ότι στο μέλλον δεν θα σου ζητήσει "αυτοπεραιώσεις"?

Το ότι κάποιος είναι στο χώρο της πληροφορικής πολλά χρόνια ΔΕΝ σημαίνει ότι μπορεί να εκφέρει νομικές γνωματεύσεις. Επίσης, το ότι κάποιες εταιρείες εξουσιοδότησαν κάποια άλλη να κάνει κάτι ΔΕΝ της δίνει το νομικό δικαίωμα να το κάνει αυτό. Υπεύθυνη δήλωση μπορεί να ζητήσει μία δημόσια υπηρεσία, ΟΧΙ μία εταιρεία ή δικηγορικό γραφείο. Αν θέλεις έγκυρη γνώμη ρώτα ένα δικηγόρο. Κάτι μου λέει ότι θα σου πει ότι δεν έχεις καμμία νομική υποχρέωση να ασχοληθείς μαζί τους. Από την άλλη, η BSA δεν αποκλείεται να ταράξει στους ελέγχους όσους δεν υπογράψουν, ακόμα και αν δεν βρεθεί απολύτως τίποτε. Θυμάται κανείς την ACS:Law που έστελνε αβέρτα απειλητικά γράμματα στην Αγγλία σε όσους και καλά "κατέβαζαν παράνομα"? Και όταν πήγαν στα δικαστήρια την θάψανε? Την προηγούμενη εβδομάδα καταδικάστηκε, είχε όμως προλάβει να χρεωκοπήσει και τη γλύτωσε με 1000 λίρες πρόστιμο αντί για το προβλεπόμενο 200.000. Όχι ότι έχει σχέση με την BSA ως εταιρεία, αλλά ως πρακτική ... Στην οποία περίπτωση το καλύτερο θα ήταν ΚΑΝΕΙΣ να μην απαντήσει, για να μην δημιουργηθεί προηγούμενο. Ακόμα και αν απλά θέλουν να μειώσουν τον αριθμό των εταιρειών που θέλουν να ελέγξουν μόνο σε αυτές που δεν υπογράψουν, η άρνηση θα τους αφήσει εκεί που ξεκίνησαν.

Όποιος έχει βρεθεί πίσω από κάμερα μάλλον γνωρίζει πόσο μανίκι είναι με μία κάμερα να τραβήξεις ομιλία και οθόνη (hint: αδύνατον). Εκ των υστέρων φυσικά φαίνεται λογικό ότι πρέπει να έχεις τουλάχιστον δύο κάμερες από τις οποίες η μία θα κοιτάζει πάντα την οθόνη, καλές ασύρματες ψείρες, σωστή τοποθέτηση ηχείων για να αποφύγεις μικροφωνισμούς και την ακουστική τουαλέτας, ασύρματα μικρόφωνα για τον κόσμο, πολύ ισχυρό μηχάνημα για editing και ακόμα πιο ισχυρό για το τελικό μοντάζ. Πολλαπλοί δίσκοι ή συστοιχίες RAID είναι η ελάχιστη απαίτηση αν δεν θέλεις το μοντάζ να κρατήσει αιώνες λόγω καθυστερήσεων στο IO. Μην ξεχνάμε ότι μιλάμε για πολλές ώρες βίντεο. Και φυσικά τα κατάλληλα άτομα (2 στις κάμερες, 1 σκηνοθέτης ίσως και 1 ηχολήπτης - εκτός και αν θες οι κάμεραμεν να κουβεντιάζουν όλη την ώρα για το ποιός θα πάρει τί και πότε), η κατάλληλη προετοιμασία στα laptop των παρουσιάσεων και δεν συμμαζεύεται. Ή τα σκας λοιπόν σε κάποιο συνεργείο για να σου κάνει αυτή τη δουλειά (όχι και πολύ φθηνό) ή θα πρέπει να βρεις τουλάχιστον 3 άτομα ανά track από το community με την κατάλληλη εμπειρία για να την κάνουν και το προγραμματίζεις με λεπτομέρεια πολύ πριν ξεκινήσει το event. Συνεπώς είναι μάλλον άστοχο να ζητάμε ποιότητα κανονικής βιντεοσκόπησης από community effort το οποίο είναι ολοφάνερο ότι δεν ξεκίνησε ποτέ με αυτή τη λογική.

skok, το server collation το ορίζεις εσύ στο setup. Δεν μπαίνει μόνο του επειδή κάτι βρήκε στο system locale.

Απόστολε αυτά που λες δεν ισχύουν. Καταρχήν το Latin1 είναι απλά άλλο ένα collation, από την άλλη το UTF8 δεν υπάρχει στον SQL Server ούτε καν σαν έννοια. Πρόβλημα υπάρχει φυσικά στην MySQL που δεν ξεχωρίζει ANSI από Unicode και προσπαθεί όλα να τα χειριστεί ως ANSI με encodings. Είπαμε, ο SQL Server υποστηρίζει unicode εξαπανέκαθεν στα πεδία nvarchar, nchar, ntext και ΔΕΝ χρειάζεται κόλπα για να παίξει με οποιαδήποτε γλώσσα, ούτε ελληνικά. Εξάλλου το τί ισχύει για MySQL δεν έχει καμμία εφαρμογή για SQL Server. Το μπέρδεμα που περιγράφεις είναι και η αιτία που διάφορες εφαρμογές δεν δουλεύουν σωστά με ελληνικά. Αν παίζεις μόνο με ANSI (varchar, char, text πεδία) θα σε κάψει το codepage. Αν βάλεις unicode δεν πρόκειται να χρειαστείς ποτέ εργαλείο για μετατροπή collation, όχι γι αυτό το λόγο τουλάχιστον. Αν τώρα κάποιοι είχαν μαζέψει τόσα δεδομένα σε ASCII πεδία, λογικό να χρειάστηκαν εργαλεία. Αλλά όπως είπα και νωρίτερα, αυτό το ρημάδι το n στους τύπους δεν κοστίζει τίποτε, ούτε χρειάζεται εργαλεία.

ASCII γράφεται σε ένα πεδίο αν αυτό είναι τύπου varchar. Αν είναι τύπου nvarchar αυτό που γράφεται είναι unicode. Θα πρέπει να μας γράψεις το script του πίνακα για να καταλάβουμε τί γίνεται (δεξί κλικ στον πίνακα, Script Table As, Create) αλλά πάω στοίχημα ότι τα πεδία είναι varchar. Το ότι κάνεις query και βλέπεις σωστά τα ελληνικά δεν είναι περίεργο. Και το Management Studio client είναι και υπόκειται στους ίδιους κανόνες με τις άλλες εφαρμογές. Το font που χρησιμοποιεί είναι Unicode συνεπώς πρέπει να μετατρέψει ότι διαβάζει σε unicode για να το δεις. Αν τα δεδομένα είναι unicode θα τα δεις κανονικά. Αν είναι ascii θα τα δεις σωστά μόνο αν τα collations είναι σωστά, αλλιώς και ο SSMS θα τα χάσει στα conversions. Αν η εφαρμογή σώσει το 0xΑ2 byte (Ά στο Windows Greek) σε πεδίο με λατινικό collation, τί θα πρέπει να σου δείξει το SSMS όταν πάει να διαβάσει αυτό το 0xA2 ? ¢ Ίσως να μπορέσεις να διορθώσεις την κατάσταση προσωρινά αλλάζοντας το system locale του server. Το λέω αυτό επειδή στο documentation του AutoTranslate λέει ότι το translaction γίνεται χρησιμοποιώντας τα ACPs του server και του client. ACP σημαίνει ANSI Code Page, με άλλα λόγια το System Locale. Ίσως να διορθωθεί το πρόβλημα σου αλλάζοντας το System locale σε ελληνικό, ίσως όχι.

..... Αν είχα 1€ για κάθε φορά .... [:S] Ο λόγος που ΔΕΝ ΠΡΕΠΕΙ ΝΑ ΧΡΗΣΙΜΟΠΟΙΕΙΣ ASCII είναι ακριβώς για να μην χρειάζεται να "καρφώνεις" τα settings για να παίξει η εφαρμογή. Και καλά αν έχεις μόνο ελληνικά δεδομένα. Αν όμως έχεις και κανένα πελάτη σε άλλη χώρα? Κανα ρουμάνικο collation ? Αν χρησιμοποιείς ένα γερό SQL Server cluster για διάφορες εφαρμογές? Άσε που αν θέλουν οπωσδήποτε να "καρφώσουν" το codepage, ας το κάνουν μέσα στην εφαρμογή, μετατρέποντας τα strings στο codepage που θέλουν με κώδικα πριν τα στείλουν στη βάση. Πραγματικά, είναι ευκολότερο (effort = 0) να κάνεις τη δουλειά σωστά και να ορίσεις όλες τις στήλες nvarchar αντί varchar από την αρχή, παρά να προσπαθείς μετά να διορθώσεις τα προβλήματα έστω και ενός πελάτη.

Το πρόβλημα οφείλεται στο ότι η εφαρμογή αποθηκεύει δεδομένα σε μορφή ASCII αντί για unicode στη βάση με αποτέλεσμα να εξαρτάσαι από το collation, τα regional settings και τον τρόπο που γίνεται η σύνδεση για το αν θα φανούν σωστά τα ελληνικά. Το πρόβλημα εμφανίζεται όταν προσπαθείς να γράψεις στη βάση με ένα codepage ενώ αυτή περιμένει κάποιο άλλο. Το τί περιμένει η βάση εξαρτάται από το collation της βάσης ή του πίνακα. Οι περισσότερες βιβλιοθήκες (OLEDB, ODBC) όταν δουν ότι χρησιμοποιούνται διαφορετικά codepages μεταξύ βάσης και εφαρμογής θα προσπαθήσουν να μετατρέψουν τα strings από το ένα codepage σε Unicode για να τα στείλουν στο server και εκεί θα μετατρέψουν το Unicode στο δεύτερο codepage για να μην καταλήξουν "κινέζικοι" χαρακτήρες στη βάση. Όσοι χαρακτήρες δεν αντικαθίστανται μετατρέπονται σε ? ή κουτάκια. Η αυτόματη μετατροπή ελέγχεται από την παράμετρο AutoTranslate στο connection string. Στο ADO.NET δεν υπάρχει αυτό απλά γιατί τα πάντα στο ADO.NET είναι Unicode. Αν τώρα άλλο είναι το codepage της εφαρμογής (ορίζεται από τα regional settings), άλλο της βάσης (ορίζεται από collation) και άλλα του γράφεις εσύ, θα έχεις πρόβλημα. Για παράδειγμα, αν πας να γράψεις ελληνικούς ASCII χαρακτήρες από αγγλικό locale σε βάση με ελληνικό collation, θα γίνει μπέρδεμα. Σε αυτό οφείλονται και οι "κινέζικοι" χαρακτήρες, είναι ASCII τα οποία "περάσανε" από λάθος μετατροπή. Αυτό που με παραξενεύει είναι ότι λες ότι η βάση είναι σε Greek locale και στο νέο server αλλά το πρόβλημα παραμένει. Αυτό σημαίνει ότι η ίδια η εφαρμογή δεν υποστηρίζει Unicode και δουλεύει με ASCII codepages. Μήπως είναι Delphi? Γιατί ακόμα και η VB6 με Unicode δούλευε. Υποψιάζομαι ότι αυτό που "χαλάει" την εφαρμογή είναι το AutoTranslate, οπότε δοκίμασε να προσθέσεις το AutoTranslate=no ή AutoTranslate=false (OLEDB ή ODBC αντίστοιχα) μήπως διορθωθεί το πρόβλημα. Η όλη ανακατωσούρα περιγράφεται και στο KB904803, όπου αναφέρει επίσης ότι "ΔΕΝ υποστηρίζεται η αποθήκευση non-Unicode δεδομένων από codepage X σε στήλη με διαφορετικό codepage". Αυτό είναι η άλλη μεγάλη (και πολύ συχνότερη_ πηγή προβλημάτων, όταν η εφαρμογή σώζει ελληνικά σε Latin στήλες. Η πραγματική λύση φυσικά είναι η εφαρμογή να αρχίσει να χρησιμοποιεί Unicode αντί για ASCII. Όλα τα άλλα είναι "χανζαπλάστ" και μπορεί να σου λύσουν προσωρινά το πρόβλημα, δεν εξασφαλίζουν όμως ότι δεν θα εμφανιστεί ξανά στο μέλλον. Αν έχεις όρεξη, ρίξε και μία ματιά στο "Ο Sql Server ΔΕΝ ΧΡΕΙΑΖΕΤΑΙ ΚΟΛΠΑ για να υποστηρίξει ελληνικά". Περιέχει τα παραπάνω λίγο πιο αναλυτικά, χωρίς το κομμάτι για το πως ακριβώς δουλεύει το AutoTranslate.

Προφανώς ... άλλο όνομα αντιστοιχεί σε διαφορετική συμπεριφορά. Επίσης, να έχεις υπόψη ότι το SharePoint ενδιαφέρεται και πολύ μάλιστα για το header καθώς με αυτό ξεχωρίζει από ποιό zone έρχεται μία κλήση (intranet, extranet, public, default) και ανάλογα ενεργοποιεί διαφορετικά policies.

Πριν το βάλεις σε άλλο μηχάνημα, τί έγινε με αυτά που σε ρώτησε ο Καπνιάς? Μήπως το team site είναι στο ίδιο port με κάποιο άλλο site? Επίσης, ποιό URL χρησιμοποιείται όταν κάνεις browse μέσα από τον IIS (το οποίο δουλεύει) και ποιό όταν κάνεις απέξω (και δεν δουλεύει)? Το σίγουρο είναι ότι η εγκατάσταση του SharePoint δεν χρειάζεται ακροβατικά, εκτός και αν το κάνεις χειροκίνητα σε Win 7. Τόσος κόσμος το έχει κάνει ως τώρα. Για να πεισθείς ότι το setup του SharePoint δεν έχει "καλικάτζαρους" θα σου πρότεινα να το εγκαταστήσεις πρώτα σε ένα καθαρό VM ακολουθώντας ακριβώς τις οδηγίες του installation guide. Μετά, θα πρέπει να καταγράψεις τί συμβαίνει. Οι πληροφορίες που έχεις δώσει ως τώρα είναι ανεπαρκείς. Με τί accounts έγινε το setup? Ποιά accounts έδωσες για τα services? Ολοκληρώθηκε ο Configuration Wizard? Τί εμφανίστηκε στα setup logs? Στο Event Log? Υπάρχουν άλλα sites στα ίδια port που χρησιμοποίησες? Χρησιμοποιείς κάπου host headers? Τα sites που δημιουργούνται είναι στην Intranet ή Trusted Zone του IE? Αυτό το zone έχει δικαίωμα να κάνει login? Τί error εμφανίζεται? Αν δεν το βλέπεις, τί γράφεται στα logs? Event log, sharepoint log, IIS log? Άλλα πράγματα που μπορείς να δεις είναι, δουλεύουν τα command-line εργαλεία του Sharepoint, το stsadm και το Configuration Wizard? Αν δεν δουλεύουν μάλλον υπάρχει πρόβλημα γενικότερο με τα accounts που χρησιμοποίησες. Δοκίμασε έτσι κι αλλιώς να ξανατρέξεις τον Configuration Wizard, μήπως υπάρχουν προβλήματα που δεν πρόσεξες

Αυτό που βλέπεις είναι ένα web site το οποίο έχει φτιαχτεί με το Team Template

Με άλλα λόγια, δεν έτρεξες από την αρχή το preparation tool το οποίο βάζει αυτό το hotfix από μόνο του, όπως αναφέρεται στο installation guide. Όσο για τη "βασική σελίδα" ίσως στο Foundation ή στα WSS να σου φτιάχνει αυτόματα ένα site collection. Δεν ξέρω γιατί μόνο μία φορά έχω στήσει foundation, απλά για να το δω. Άλλο αυτό, άλλο το αν υπάρχει κάποια "βασική σελίδα". Να επαναλάβω ότι το SharePoint δεν είναι εφαρμογή η οποία εγκαθίσταται με ένα wizard, ούτε μπορεί κανείς εύκολα να διορθώσει προβλήματα αν δεν καταλάβει τις βασικές του έννοιες.

Αυτό το fix είναι πολύ παλιό και δεν σημαίνει ότι έχει να κάνει με το πρόβλημα σου. Επιπλέον αφορά μόνο client λειτουργικά. Εσύ πού προσπάθεισες να εγκαταστήσεις το SharePoint? Και αν δοκίμασες να το βάλεις σε client, πως το έκανες? Η διαδικασία είναι χειροκίνητη οπότε αποκλείεται να την έκανες με το wizard. Καταρχήν, με ποιό URL προσπαθείς να συνδεθείς? Βρίσκεται αυτό το URL στα trusted sites ή τα intranet sites του IE για να γίνεται αυτόματα Login? Συνδέεσαι με το ίδιο URL που χρησιμοποιεί και ο IIS όταν κάνεις browse? Συνδέεσαι ως ο ίδιος χρήστης που έκανε την εγκατάσταση? Τί θα πει "τόσο στη βασική σελίδα"? Κατά την εγκατάσταση δημιουργείται μόνο το Central Administration, δεν υπάρχει "βασική σελίδα". Μήπως μετά την εγκατάσταση έφτιαξες κάποιο site και μετά έχασες την πρόσβαση σε αυτό? Αν συνέβει αυτό μήπως αφαίρεσες τα κατάλληλα δικαιώματα από το account σου χωρίς να το θέλεις? Όταν τελειώνει η εγκατάσταση και ο configuration wizard εμφανίζεται το central administration και σου ζητάει πληροφορίες για να ρυθμίσει και να ξεκινήσει διάφορα services. Έφτασες σε αυτό το σημείο? Ολοκλήρωσες τον wizard? Τέλος, είναι πολύ κακή ιδέα να ανακατώνεις τα user groups και τα permissions που χρησιμοποιεί το SharePoint αν δεν ξέρεις ακριβώς τί γίνεται, γιατί άνετα μπορείς να φτάσεις σε σημείο είτε να μην μπορείς να μπεις ή να μην ξεκινάνε τα services.

giotis, δεν είναι όλοι οι πελάτες ίδιοι, ούτε όλες οι εταιρείες απευθύνονται στους ίδιους πελάτες. Μπορεί για εταιρείες <100 ατόμων να φαίνονται πολλά τα 20K, αλλά υπάρχουν πάρα πολλές εταιρείες που έχουν >100 υπαλλήλους. Το email είναι η πιο critical εφαρμογή μίας εταιρείας. Άνετα τα δίνουν τα 20k.

Ποιά εκμετάλλευση και ποιά Ελλάδα? Και τί δουλειά έχουν τα αυτοκίνητα με τη δουλειά που κάνεις για την εταιρεία σου, ως υπάλληλος της? Ποιό ξεζούμισμα? Πως είναι δυνατόν να "έτυχε" να φτιάξεις κάτι για την εταιρεία σου? Το χρησιμοποιεί ή όχι η εταιρεία σου αυτό που έφτιαξες? Άσε που αν δουλέυεις σε συνεργείο και φτιάξεις 4 ζάντες, ΔΕΝ μπορείς να τις βουτήξεις και να φύγεις. Προφανώς κανείς δεν σε εμποδίζει να φτιάξεις άλλες ζάντες, αλλά αυτές τις 4 ΔΕΝ μπορείς να τις βουτήξεις. Άσε αν μιλάμε για ένα τηλεφωνικό κατάλογο ανήκει κατευθείαν στα τετριμμένα. Αυτό ε, ναι, κανείς δεν σε εμποδίζει να το χρησιμοποιήσεις ως έχει. Πολλές φορές όσοι δεν είναι επαγγελματίες προγραμματιστές κάνουν κάτι το οποίο σε αυτούς φαίνεται δύσκολο και σίγουρα πολύ πιο σημαντικό απ' ότι μπορεί να είναι στην πραγματικότητα. Αν μιλάμε για εφαρμογή τηλεφωνικής ατζέντας (Outlook κανείς?) μιλάμε για κάτι το οποίο μπορεί να φτιαχτεί άνετα μέσα σε 1 μέρα, και αν μάλιστα χρησιμοποιήσεις κάποιο framework όπως το Express App Framework της DevExpress, σε 1-2 ώρες.

Τα πράγματα δεν είναι τόσο σκοτεινά, ούτε όμως και εντελώς ξεκάθαρα. Στην περίπτωση σου πάντως μάλλον δεν έχεις και καμμία ελπίδα, εφόσον η εφαρμογή αφορούσε την δουλειά που έκανες στον εργοδότη σου, την έκανες για τον εργοδότη σου, δεν υπήρξε καμμία ειδική συμφωνία εκ των προτέρων και χρησιμοποιήθηκε για μεγάλο διάστημα χωρίς να διαμαρτυρηθείς εσύ. Πολύ χονδρικά, και με διαφοροποιήσεις από χώρα σε χώρα, υπάρχουν τρείς τρόποι να κατοχυρώσεις κάτι: copyright, trade secrets και ευρεσιτεχνίες. Οι ευρεσιτεχνίες σου δίνουν το δικαίωμα εκμετάλλευσης μίας σχεδίασης (ή και τρόπου εργασίας στην Αμερική) απαιτώντας όμως να δημοσιοποιήσεις τη σχεδίαση σου. Δεν ισχύουν εκ των υστέρων, οπότε δεν σε καλύπτουν. Εξάλλου, δίνονται μόνο για ουσιαστικές σχεδιάσεις και απαιτούν αρκετό τρέξιμο και νομικά σκαμπανεβάσματα. Άσε που το μόνο που σου προσφέρουν είναι το δικαίωμα να κάνεις αγωγή σε όποιον παραβιάζει μία δική σου ευρεσιτεχνία. Θα πρέπει εσύ να βρεις τα γκαφρά για να βγάλεις σε πέρας την αγωγή. Το copyright αφορά την προστασία αυτούσιων έργων όπως κειμένων, τραγουδιών, ή κώδικα. Από τη στιγμή που η δουλειά έγινε για τον εργοδότη σου, μάλλον αυτός έχει και το copyright. Άρα δεν μπορείς απλά να αντιγράψεις τον κώδικα ως έχει. Copyright δεν ισχύει για τμήματα τα οποία είναι τετριμμένα ή είναι ο διαδεδομένος τρόπος να κάνεις κάτι, π.χ. δεν μπορείς να επικαλεστείς copyright επειδή κάποιος ανοίγει σύνδεση στη βάση με τον ίδιο τρόπο όπως κι εσύ. Τα trade secrets όπως λέει και το όνομα είναι θέματα που αφορούν το συγκεκριμένο τρόπο που δουλεύει μία εταιρεία. Τα πράγματα είναι λίγο νεφελώδη στο τί ακριβώς είναι trade secret αλλά οι περισσότερες συμβάσεις περιέχουν σχετικούς όρους, είτε είσαι υπάλληλος είτε ελεύθερος επαγγελματίας. Σε αυτή την κατηγορία ανήκουν π.χ. η συνταγή της Coca Cola. Trade secret πάντως δεν είναι κάτι το οποίο είναι κοινό για όλες τις εταιρείες του κλάδου, το ανακάλυψες μόνος σου μέσω reverse engineering ή το κοινοποιεί η ίδια η εταιρεία σου. Αν δεν είναι μυστικό,τί είδους trade secret είναι? Από τα παραπάνω, μόνο αν είχες ευρεσιτεχνία θα μπορούσες να οφεληθείς. Τα υπόλοιπα εξυπηρετούν τον εργοδότη σου. Αυτό που κανείς δεν σε εμποδίζει να κάνεις όμως, είναι να χρησιμοποιήσεις τις γνώσεις σου για να φτιάξεις μία νέα εφαρμογή την οποία θα μπορούσες να εκμεταλλευτείς. Όσο δεν χρησιμοποιείς κομμάτια του παλιού κώδικα, ή δεν χρησιμοποιείς γνώσεις που αφορούν αποκλειστικά τον παλιό σου εργοδότη, δεν μπορούν να σου πουν και πολλά. Εκτός και αν υπάρχει συμφωνία που σε δεσμεύει. Στη θέση σου θα ξεκίναγα από την αρχή την εφαρμογή, και για να αποφύγω θέματα copyright αλλά και γιατί πάω στοίχημα ότι το χρειάζεται. Ένα macro που κάνεις στα γρήγορα για να βγει πέρα η δουλειά έχει πολύ λιγότερες απαιτήσεις από ένα πακέτο που εκμεταλλεύεσαι εμπορικά.