Kirikiri 2 game error under Window 10 Unable to load the plug-in windowEx.dll - 修正 吉里吉里 2 報錯解決

To run Kirikiri 2 under window 10 environment , error "An exception occurred in the script Unable to load the plug-in windowEx.dll" may be popped up and lead to application crash (or cannot start the game).

Japanese version : 例外が発生 プラグイン windowEx.dll を読み込めません 

English version : An exception occurred in the script Unable to load the plug-in windowEx.dll

The error can be fixed by installing Microsoft Visual C + + 2010 Redistributable Package (x 86) 

Exact file needed : vcredist_x86.exe

Download page : Microsoft Official Link

Salesforce Record Security : Troubleshoot the Insufficient Privileges Error 檢查 Salesforce 權限不足錯誤

Insufficient Privileges Errors often shown when user attempts to access the record that he/she does not have right permission to read or edit .

Procedure Quick Notes :
(Obj.) User Profile > Permission Sets > (Rec.) OWD > Sharing Rules > Manual Sharing 

First of ALL , make sure the user REALLY does not have the right permission by SOQL below :

SELECT RecordId, HasReadAccess, HasEditAccess FROM UserRecordAccess WHERE UserId = [theUserID] AND RecordId = [theRecordID]

Then , try to check from Object level permission to Record level permission.
*If user can read the record (HasReadAccess=true), then checking of object level security can be skipped.

The security setting about record access in salesforce can be divided into two major levels : 

• Object level (*there is Field level under object level)
• Record level

Setting related to Object level permission 

Object level security determines the baseline level of access for ALL the records in an object.
It controls which object user is permitted to perform CRUD operation in high level.
#CRUD = CREATE,READ,UPDATE,DELETE.

1. Profile
    User profile controls the object and its field permission , it also can be used to grant ALL                       record access/modify permission

• Way of checking

1. Setup > Quick Find box > Search Users > User list page > click the User’s profile.
2. On the Profile overview page, go to Object Settings or Object Permissions.

2. Permission Sets.
    Permission Sets also controls the same permissions as profile. The main different is the permission         can be assigned to specific single user(s) one by one .

• Way of checking

1. Setup > Quick Find box > Search Users > User list page > click the User 
2. On the user detail page, scroll to the Permission Set Assignments related list and click each permission set.
3. On the Permission set overview page > Object Settings and review the assigned object permissions.

Common Question : Salesforce do permission sets override profiles ?

#Profile and Permission Sets act as "AND" setting approach .Which means as long as the permission is granted by profile or permission sets either one (or both) , the user owns the permission already.

Answer from internet about Permission Sets VS Profiles 
The settings and permissions in permission sets are also found in profiles, but permission sets extend users' functional access without changing their profiles.

Setting related to Record level permission 

Record level security determines the record accessibility of data that owned (created) by other users.

*Profile and Permission sets could grant "View all record" and/or "Modify all record" to an object. If these two permissions have been chosen, the "ALL" permissions above override the record level setting.

3. OWD ( Organization Wide Default ) 
     OWD specify the basic accessibility of user has to each other’s records. It can be divided
     as two types : Private , Public , [Controlled by Parent] .

• Way of checking

1. Setup > Quick Find box > Search Sharing Settings > click Sharing Settings
2. The top section is about OWD     

•     Private record only grant access to record owner , and those roles above record owner.
• For Custom object, the "Grant Access Using Hierarchies" can be disabled (deselected). Which means blocking record access through role hierarchy . 
• i.e. Blocking supervisor from accessing the data owned by their subordinate. 
•     Public record can be access by ALL users , and can be categorized into three sub-types : 
• Read-Only , Read/Write , [Read/Write/Transfer] 
• Transfer right only selectable to some standard object like Lead , Case etc.
•     Controlled by Parent record applied to child object that belongs to "Master-Detail"   
        relationship only.
• If user has access to the parent (master) record, user will be able to view the child (detail).

4. Sharing Rule ( Role , Public Group , Users )
    The rules specify access sharing of Private Object record on top of OWD. While OWD share
    record based on owner role under same hierarchy branch , sharing rule can be used to further share
    record based on different criteria including owner and other record characteristic. 

    And in contrast to OWD which share record to role above record owner on the hierarchy branch,,
    sharing rule allow to share record to any role(s) and their sub-ordinates , it also enable the sharing
    to specific user(s) or public group .  

• Way of checking
1. Setup > Quick Find box > Search Sharing Settings > click Sharing Settings
2. The middle to bottom section is about sharing rules
   

• Share based on Record Owner 
• Owners can be identified through public groups, roles and roles, and sub-ordinates ,while OWD only identified owner role and OWD does NOT allow cross-branch role  (could be consider as other department) sharing of private record.
  
  For example , we can share record created by Salesman A which is under Sales department to Sales manager(s) and users under Accounting department through sharing rules while OWD may NOT allow record share to Accounting department user under hierarchy below . 

                

• Share based on Record Criteria
• This setting enable sharing which is NOT related to record owner, but record's characteristic. 
  
  For example , we can share opportunity (record) which has Expected Revenue over $1M to marketing manager . 
  

5. Manual Sharing 
    While OWD and sharing rules can be used to share a group of records , manual
    sharing can be used to share specific single record manually , one by one . 

     Only user(s) has/have "HasAllAccess" can share the record manually to other(s).
    To check who can share the record manually ,use SOQL below :

SELECT UserId, HasAllAccess FROM UserRecordAccess WHERE RecordId = [theRecordID]

• Way of Checking

• Record detail page> Sharing button (Classic version)
• Record > Sharing button > Edit link (Lightning version)

• Share by Sharing Button 
• Record owner, role above record owner , user that has "Modify All Data" permission in profile/permission sets and administrator can view all users/groups who has access to that record, and can add share user to that specific record using that button. 
  *Sharing Button can be added via page layout by administrator if you cannot find it .
  
  
• There are different sharing reasons of record, for those using manual sharing , usually the share reason will be "Manual Sharing". Full share reason list can be found in official site.
  
*Record owner change may lead to lost of manual sharing.

• Share by Apex coding API
• The default sharing reason of Apex code adding access is the same as using sharing button UI . (Which is Manual Sharing)
• Administrator can create up to 10 sharing reason for each custom object.
• Developer may select the custom sharing reason in code, for distinguish purpose.
• Deleting an Apex sharing reason will delete all sharing on the object that uses the reason.
• Method to create sharing reason can be found in official site.

Summary

- There are 2 main level of sharing : Object level and Record level. 

- *Field level permission could be set to different profile which controls fields could be access in object.

- Things need to be checked during troubleshoot include Profile , Permission set if user cannot view any record of that object . If there are some records cannot be accessed , then OWD, Sharing Rule and Manual Sharing can be checked.

- Official Reference about record sharing 

- Apex Code Sample of Manual sharing  (TODO)

Batch script commands to combine text(.csv) files 使用命令提示字元合併多個文字檔案

Code Preview

copy *.csv all.csv #For flatten file structure 單一資料夾檔案合併

for /R %f in (*.txt) do type "%f" >> all.txt #For merging sub-folder files 多層資料夾檔案合併

There are lots of use cases that we have to handle numbers of fragment files . One of the the common operation is to combine text files into a single file. You may find section below helpful if you have to merge multiple text files. 

Scenario 

Case A : Combine csv data feed into single Excel sheet for filtering and analysis.

Case B : Collect all intranet system log for investigation .

The task is easy but can be time consuming , and the task actually can be done using command line within 3s. There are mainly two ways to combine text files in command line.

Method 1 
The simple way is using copy command for NO sub-directory file case   

Flatten file structure

The command 

copy *.csv all.csv

Result 

The Command above mainly choose the files to merge in the folder by selecting file extension .

It tells window to merge all .csv file in folder "C:/Users/Local User/Documents" into a file named as "all.csv".

Alternatively, you may also use the wildcard symbol * in file name like below :

The command  

copy b*.csv b_all.csv

Result 

The command merge .csv files with prefix letter "b" in filename into file named as "b_all.csv".

Method 2
The customized way is using for /R to handle recursive selection in sub-directory   

There are certain text log files in the sub-folders , those files need to be combined as well. 

Hence the folder has to be searched recursively in order to find out all the files inside sub-folders.

The command 

for /R %f in (*.txt) do type "%f" >> allLog.txt

Result 

All .txt file inside the folder "C:/Users/Local User/Documents" and its sub-folders will be merged into a file named as "allLog.txt".

Summary

- Text files could be merged using command "copy" or "for /R".

- The first method only apply to situation with flatten file structure while the second could      be applied to sub-folder structure.

- Wildcard symbol * could be used for filename or file extension selection.

Hello World

Start with Hello World as a tradition.

Try to enter code block to blogger using Hilite.me !

Test code sample in salesforce Apex format.

@isTest
private class HelloWorld_Test{
  static testMethod void createHelloWorld() {
        Account a = new Account(name='Hello World');
        insert a;
        System.debug(LoggingLevel.INFO, 'Hello World account ID :' + a.Id);
  }
}

End of code block Test.